Re^2: Debian Documentation Hierarchy
Am 27.04.98 schrieb apharris # burrito.onshore.com ...
APH> * modularity of design; no hardcoded knowledge of various
APH> documentation display systems (info, dwww, dhelp)
APH> * ease of use by debian package developers (i.e., in maintainer scripts)
APH> * utmost rebustness in the face of package remove, purging,
APH> reinstallation, multiply shared /usr or /usr/doc dirs, etc.
APH> * minimize system impact for end-user (i.e., installation speed)
APH> This type of arrangement would decouple doc-base from the dww/dhelp,
APH> i.e., if dhelp_parse syntax changed right now, I'd have to re-release
APH> doc-base to accomodate that, which is sub-optimal.
APH> I currently believe that document language is an attribute of a
APH> particular flavor of a document, and as such it should be handled as
APH> such in the docid registration file. Display issues, again, are my
APH> least concern right now; I want to *enable* radically effective
APH> display systems, without actually telling them how they should go
APH> about it.
Ok, let#s start the discussion on the file format. I#ve downloaded your
doc-base 0.6 package and read the file format description of doc-base. We
could use that as basis for our file format.
doc-base 0.6 doesn#t work on my system. I#ve send you a bug report. And
I#ve uploaded dhelp 0.3.7 to fix you dhelp_parse problem. I hope this will
fix your problem.
APH> if a system which provides documentation complying with the guideline,
APH> is it ok to submit a bug? If so, at this point, you could file your
APH> "pre-rolled" docreg files for various packages as bugs (with patch
APH> included) against the packages themselves.
Uni: Budde@tu-harburg.de Fido: 2:240/5202.15
Mailbox: firstname.lastname@example.org http://www.tu-harburg.de/~semb2204/
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org