Re: Re^2: strange behavior of dh_dhelp
mbudde@sms.antar.com (Marco Budde) writes:
> Am 28.09.99 schrieb roland # spinnaker.de ...
> 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?
Because doc-base is generic.
> 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 :(((.
Why don't you solve it then, by adapting dhelp to use the doc-base format?
If the mountain won't come to Mohammed, Mohammed must come to the
mountain.
> Please tell me what for do we need doc-base? We need a file format and not
> a converter!
doc-base _is_ a file format, among other things.
> 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 :(?
There _is_ one format. It is called doc-base and, so far, it is the
best compromise.
> 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 :(.
So what.
> 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.
By the same token, why should we support dhelp then? It has been
developed later than dwww.
> 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.
The fact that we don't have a single unified documentation system is
not a good sign for Debian's quality.
You are partly to blame for that.
> RR> dh_make for a long time now. So doc-base may be a good compromise as
> RR> the "one file format".
>
> No.
Why not? So far you have given no arguments other than that you don't
like it.
> 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.
Maybe you should use some common sense.
> 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.
At the moment (at least for the potato release) it is /usr/doc/ as
decided by the tech ctte.
> 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.
Why not? A well-configured http daemon can be configured so that
symlinks from /usr/doc will be allowed but not from other locations.
> 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.
READ THE FSCKING TECH CTTE DECISION.
> 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.
Then read the debian-policy archives and the tech ctte decision.
Surely if it would be that simple, why was there such an amount of
discussion about it.
> 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.
Good for you.
> 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.
One last request. Can you please use the ASCII character set in your
messages? Those # (hash marks) instead of apostrophes do not help the
readability of your messages.
- Ruud de Rooij.
--
ruud de rooij | *@spam.ruud.org | http://ruud.org | http://weer.moonblade.net
Reply to: