Re^2: strange behavior of dh_dhelp
Am 28.09.99 schrieb roland # spinnaker.de ...
Moin Roland!
RR> > installation process? There#re two better solutions: 1) All programs use
RR> > the same file format.
RR> Okay, simply change dhelp to use the doc-base directly and were are done.
ROTFL, why should I change dhelp to support a broken file format? I#ve
discussed a new file format with the author of doc-base (read debian-doc).
But the author is not interested to solve this problem :(((.
Please tell me what for do we need doc-base? We need a file format and not
a converter!
RR> > 2) You can convert the files during dpkg-buildpackage offline.
RR> That's a bad idea, because this restricts you from adding new
RR> documentation systems which use another new format. Have a look how
Of course the first solution is a lot of better. But how should we solve
problems when the authors are not interested to find one file format :(?
RR> many packages still only support dwww and not dhelp. So you see, that
RR> creating these files at build time is a bad idea, while using a
I don#t see that.
RR> generic format like doc-base is much more flexible, because you only
Why is doc-base a generic format? It#s as generic as the dhelp/dwww
formats. In fact the format has got a lot of disadvantages.
RR> > Why is dhelp broken?
RR> Because it doesn't support /usr/doc symlinks in the /usr/doc tree when
RR> the .dhelp file (created by a doc-base file) mentions the real
RR> (/usr/share/doc) path.
Example, please.
RR> Why do you mix the speed of install-docs and dwww here? The first one
Because install-docs slows down the speed of dhelp :(.
RR> browsing. As far as I can see one has nothing to do with the other.
The slow speed.
RR> > Because some authors are not interested to solve problems :(. We
RR> > don#t need something like doc-base.
RR> When I read the second sentence, it seems that you're talking about
RR> yourself in the first one =;-)
Why? What for do we need doc-base? I#ve offered several times, to find
*one* format for all programs, but without any success.
RR> > We need only a small shell script, that calls dwww and
RR> > dhelp_parse. And we need *one* file format for dwww and dhelp.
RR> So why not use doc-base as this one file format?
Why? doc-base has been developed later that dhelp/dwww and it#s useless.
So why should we move to it#s file format? This makes no sense.
RR> All file formats (doc-base, dhelp, menu,...) will have advantages and
RR> disadvantages.
Right, so merge all advantages and find a new file format. We#ve thought
about a Dublin Core clone, but after 1,5 year there was no result. I don#t
understand the difficulty to define a file format :(.
RR> As far as I can see doc-base is a little bit more
RR> flexible than dhelp (the latter only supports HTML and no other
dhelp supports all formats. And doc-base has got a lot of disadvantages:
for example absolute file names, where dhelp uses relative file names like
the html format does.
RR> doc-base is widely used
In fact a lot of packages don#t use doc-base, dhelp or dwww. For example
the libc maintainer closed such a bug report without adding support for
these programs. This is not a good sign for Debian#s quality.
RR> dh_make for a long time now. So doc-base may be a good compromise as
RR> the "one file format".
No.
RR> I think that it is possible, proposed that all packages which use only
RR> /usr/share/doc at the moment, will soon add a symlink in /usr/doc, to
RR> follow the technical committee decision. Than you only have to
Maybe they should start fixing the policy. If we continue working with
this speed, the next release will be released 2010.
RR> support /usr/doc with one problem:
No. We need a decision: which one is the *main* doc directory. Which one
should the user use. At the moment I would suggest /usr/share/doc.
RR> the doc-base and .dhelp files point
RR> to the real location in /usr/share/doc,
.dhelp does not point to this directory. Here you see one advantage of my
format: dhelp uses relative file names. In fact you could add the same
.dhelp file to both: /usr/doc and /usr/share/doc.
RR> while the files are also
RR> accessible via the symlink as /usr/doc/<package>. There needs to be
One again: they are *not* accessible via these symlinks! This may work
sometimes but not always -> hack. A good configured http daemon will not
follow these symlinks.
RR> some work around for this, but this should be possible with some Perl
RR> or Shell knowledge.
dhelp is a offline system. dhelp doesn#t convert things during runtime
like dwww does.
RR> No problem when you see /usr/doc as the one and only directory for
RR> accessing the files.
??? But we use /usr/share/doc. Read the policy.
RR> The documentation of every package should be
RR> available as /usr/doc/<package> in potato (this will change in the far
RR> future, but now we are working on potato).
Great and the next Debian release will have the same or even more
problems. I don#t like such hacks. In fact I don#t understand why we
should not simply move our documentation to the new directory.
RR> decision. Maybe you noticed, that newer versions of debhelper and
RR> lintian already support this way to handle this.
I don#t use debhelper.
RR> That's not true. At least apache supports following symlinks when you
RR> activate this with "Options FollowSymLinks" in access.conf for the
RR> /usr/doc directory. Other web servers will support this in a similar
RR> way.
Will apache follow symlinks in /usr/doc or symlinks to all possible files?
Using this feature could course real security problems. And of course
there#re other http daemons than apache.
cu, Marco
--
Linux HOWTOs - Die besten Loesungen der Linuxgemeinde
ISBN 3-8266-0498-9
Uni: Budde@tu-harburg.de Fido: 2:240/6298.5
Mailbox: mbudde@sms.antar.com http://www.tu-harburg.de/~semb2204/
Reply to: