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

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  

RR> I just installed it, but as far as I can see this doesn't integrate

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: