Re^2: strange behavior of dh_dhelp
Am 25.09.99 schrieb roland # spinnaker.de ...
Moin Roland!
RR> > Why? What is the advantage of using doc-base?
RR> It is always a good idea to use a generic format which can
RR> automatically converted to all useful formats instead of using one
RR> special format.
No, sorry, but this is wrong. Why should we convert files during the
installation process? There#re two better solutions: 1) All programs use
the same file format. 2) You can convert the files during dpkg-
buildpackage offline.
I#ve discussed more than one year with the doc-base author about (1), but
without a result :(.
RR> documentation system next to dwww and dhelp (both are horribly broken
RR> at the moment, so another one may be a good idea) without changing all
RR> the packages.
Why is dhelp broken? Feel free to send ideas or patches.
RR> If you think, that install-docs is too slow and dhelp-parse in
One reason to write dhelp was the speed of dwww.
RR> combination with dhelp2dwww.pl is so much faster, why don't you simply
RR> rewrite install-docs in C? Then we have a generic and fast solution.
Because some authors are not interested to solve problems :(. We don#t
need something like doc-base. We need only a small shell script, that
calls dwww and dhelp_parse. And we need *one* file format for dwww and
dhelp.
RR> I just installed it, but as far as I can see this doesn't integrate
RR> FHS and FSSTND
Right, because this is not possible.
RR> trees one next to the other. Now I can read parts of the
RR> documentation as http://localhost/doc/ (which points to /usr/doc/) and
RR> others as http://localhost/fhs/ (which points to /usr/share/doc/).
RR> But I would prefer these two trees to be merged. This should be
I would prefer *one* directory.
There#s no solution for this problem, because dhelp supports reading
documents via the local file system and via the http protocol.
RR> possible for most packages, because the tech-ctte decided that every
Were can I read this? I#ve found nothing about this in the latest policy.
RR> package that uses /usr/share/doc/<pkg> has to create a symlink
RR> /usr/doc/<pkg> pointing to /usr/share/doc/<pkg>. So all documentation
RR> should be available as /usr/doc/<pkg>.
No. A http daemon will never follow this symlinks. They#re 100% useless
when using the http protocol.
RR> The only problem is, that
RR> dhelp doesn't support those links at the moment. My packages which
dhelp and all other tools can not support these links, see above.
RR> In the past we had two places where the user had to look for
RR> documentation on programs: http://localhost/doc/HTML/ and
RR> http://localhost/dwww/menu.html
??? You only need one of this systems.
RR> - Imlib Programmer's Guide dhelp/FHS dwww
RR> - XFIG User Manual dhelp/FHS dwww
RR> - TIFF Software dhelp/FSSTND
RR> - pstoedit dhelp/FSSTND
Send a bug report. But some maintainers, like the maintainer of libc6,
close such bug reports without solving the problems :(.
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: