[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> 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.


> 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: