[EMAIL PROTECTED] (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 | [EMAIL PROTECTED] | http://ruud.org | http://weer.moonblade.net