Christian Schwarz <[EMAIL PROTECTED]> 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 discussed before. .....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
