## Nachricht vom 11.04.98 weitergeleitet ## Ursprung : doc-debian # [EMAIL PROTECTED]:9000/0 ## Ersteller: Marco [EMAIL PROTECTED]: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: [EMAIL PROTECTED] Fido: 2:240/5202.15 Mailbox: [EMAIL PROTECTED] http://www.tu-harburg.de/~semb2204/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
