Re^2: document registration policy needing to be written
## Nachricht vom 11.04.98 weitergeleitet
## Ursprung : doc-debian # lists.debian.org@243:9000/0
## Ersteller: Marco Budde@243:1000/1.15
Am 11.04.98 schrieb schwarz # monet.m.isar.de ...
Moin Christian!
CS> I disagree. I still think that registering documents to install-docs does
CS> make sense, even if dwww and dhelp share a common format:
I disagree with you :).
CS> * As soon as we start with the document conversion stuff (you can't
CS> exclude this aspect of doc-base completely in this part of the
CS> discussion), packages would have to register their documents to
CS> doc-base _and_ to dhelp/dwww.
No, that#s not true. dhelp/dwww will keep informations of the HTML
documents and doc-base of the sgml, ps, info, etc files. And we#ve to
discuss, if we should do an online conversion.
CS> * Even if you say dhelp/dwww will handle only HTML while doc-base will
CS> handle all other formats, doc-base is required: there are currently
That#s only true in some cases.
CS> 3 different HTML formats that have been requested by the users during
Sorry, but we have never ask users but only developers.
CS> the last doc policy discussion: plain HTML, HTML.gz, and HTML.gz with
That is not a problem. I could add a configuration file. If doc-base
compresses the documents, dhelp adds .gz to all its entries.
CS> fixed hyperlinks. Converting between these formats would be trivial
Are you sure, that this is trivial (for example dkpg)?
CS> * As you stated above, there might be other online menu systems in the
CS> future which might use a different registration scheme.
This is not a problem.
CS> Are there any specific reasons you don't want to have the registry code in
CS> doc-base?
It#s slow. And this is important if you install some hundret packages.
CS> install-docs for each installed document: if they could just place a file
CS> in /usr/share/doc-base/registry (or something similar) and run
CS> `update-docs,' doc-base could search this directory for new entries. Same
That#s a bad idea, please keep speed in mind! Searching is never a good
idea. And where#s the problem, if you have got several files? Just call
dh_dhelp and you postinst and prerm scripts are ready. And if you like to
have only one .dhelp file for several directories, this is no problem.
CS> goes for the prerm procedure. With that, doc-base wouldn't fail if it is
CS> installed _after_ a doc package is installed.
No problem for dhelp. When dhelp is configured it searches /usr/doc for
.dhelp files. But only during configuration of the dhelp package. After
the configuration only new .dhelp files are added to the database.
CS> 1. Marco indicated in a private mail discussion with myself yesterday,
CS> that dhelp does have the functionality to search for .dhelp files in an
CS> arbitrary directory. With that, it might be possible for doc-base to put
CS> all .dhelp files in /var/lib/doc-base/dhelp/<doc-id> and run dhelp's
No, sorry. /usr/doc has to be part of the directory! This is necessary for
relative <filename>s.
CS> soon.) Moving `registry' directories like /var/lib/dpkg is nearly
CS> impossible (we'll not move this directory, for example) but this would be
CS> required if we aimed 100% compliance with FHS (we'll not do). Therefore,
CS> I'd suggest we use FHS paths right from the start.
This shouldn#t be a problem. But dhelp was never designed for dyn. created
.dhelp files!
CS> * The format has to be supported by the package maintainers (only), so
CS> we should try to make life most easiest for them. The `dpkg style'
CS> control file syntax doc-base uses until know should be known to any
CS> developer already.
But the syntax of control is terrible. For example the description with
the blank at the beginning. This is not good if the developers creates the
.dhelp/dwww file with a script.
CS> * Just using a SGML-like file syntax but by picky about where line breaks
CS> and spaces may appear (that's like dhelp behaves now) is even worse,
CS> since the SGML-like syntax makes the maintainers think doc-base doesn't
CS> care about spaces--a fail. (This happened to me with dhelp.)
RTFM and you don#t have problems :). I#ve got the same problems with for
example the control file. A developer has got always such problems, if
there#s no good documentation.
CS> Yes, that's an important point. Note, that people suggested before that we
CS> use the same menu structure which is also used for the `application
CS> menus'. However, I don't think this structure works well with
CS> documentation.
I agree, I#ve posted the structure of dhelp. Maybe somebody could post the
structure of menu? Let us start with this problem.
And remember, a package can define new <diretory>s with the dhelp system.
cu, Marco
--
Uni: Budde@tu-harburg.de Fido: 2:240/5202.15
Mailbox: mbudde@hqsys.antar.com http://www.tu-harburg.de/~semb2204/
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: