Re: doc-base 0.4 and other issues
Christian Schwarz <email@example.com> writes:
> On 16 Apr 1998, Adam P. Harris wrote:
> > (a.3) Should we reconsider the 'document-id' system (one docid per
> > file, many formats)? Wouldn't it make it easier for package
> > maintainers to have a single file that could have multiple
> > document-ids? Would this be a bad idea?
> Huh? Sorry, but I don't get your point. The DOCID is used to identify a
> document. It's like the `Package:' field of a .deb or `Source:' field of a
> .dsc file. It _has_ to be unique, since that's what the field is for.
> Note, that this field will also eventually be used for inter-document
> cross-references, as what's planned for debiandoc-sgml.
> Please give me more details about which problems you see with the current
> use of the Document-ID field.
Christian, I understand and do not question the notion that we need a
unique documentid. (Although this raises the issue that we may need
to put in processes to resolve conflicts.)
I was questioning the fact that we have one and only one documentid
per document control file. I was asking what are the good reasons (I
know they're there) behind this so I can explain it as part of my new
document registration file format standard.
> > (a.4) What file location is going to work given, say, a shared,
> > NFS-mounted /usr?
> I need more details about this, too.
Yes, maybe Manoj can pipe in here?
> Note, that there are two different kind of files: those which are only
> touched at installation time (and thus could be on a /usr directory) and
> thus which could be touched at run-time, for example, if the user suddenly
> wants to get some PostScript printed documentation.
Yes, right now we're looking at /usr/share/doc-base as the location
for the former, and /var/state, I think, for the latter, as we
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com