Re: current document policy ?
Clarifying my own response here:
>>>>> "Adam" == Adam Di Carlo <adam@onshore.com> writes:
>>>>> "John" == John Lapeyre <lapeyre@physics.arizona.edu> writes:
John> Thanks to everyone who responded. I am getting my packages
John> registered with menu and doc-base for potato. I am a bit
John> concerned about doc-base. I understand that doc-base has some
John> design flaws that you want to fix.
To clarify this, there are is one design flaw with doc-base, which is
more of a flaw with the whole system:
local documentation chain can get into wierd states, and
debugging can be hard (this is when you combine maintainer scripts
in any order, dhelp, and dwww). I've worked out a solution in
principle, where a central 'document store' is maintained in
/var/state in RDF format. Display systems can either hook into
particular document installation events, reading the individual
metadata (as they do now), or can use the central store directly.
Note: this problem is one where a generic 'post dpkg run' hook
mechanism would help enormously.
There are a few "misfeatures" or things I want to fix:
(a) more metadata tags -- I'm intending to use the Dublin core
metadata standard, while still accepting the old format files.
(b) extensible handling of file formats (i.e., info files could be
handed off to install-info) -- again, solvable with a hook mechanism
(c) display systems such as dwww and dhelp should use a
"interchange" format and not read directly the file formats that
packages feed to doc-base; this gives us the flexibility to offer a
few different formats to package maintainer. My hope is to extend
debiandoc-sgml so you don't even need a separate metadata file
(d) extensible menu heirarchy
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: