Re: Re^2: document registration policy needing to be written
Marco.Budde@hqsys.antar.com (Marco Budde) writes:
> Am 13.04.98 schrieb apharris # burrito.onshore.com ...
> APH> It's going to be hard to agree on much if I can't bringing you around
> APH> to agree on this, Marco.
>
> I would suggest the following:
>
> 1.) doc-base is called for the directories including our SUD file
> in postinst and prerm scripts of each package
> 2.) doc-base calls all index programs like dhelp/dwww, if the
> file includes HTML documents
> 3.) dhelp/dwww read the SUD file and write an index
Yes yes yes yes yes, you see the point of doc-base: to provide an
infrastructure for document display (and conversion) systems to hook
into. At last!
[details of mythical and it's too late at night to think about
document conversion ommitted]
> APH> to putting files under /usr/doc/<pkg>:
> APH> * users will be tempted to edit them directly (which is bad)
>
> Why should they? And if the edit this files, this is not a problem.
>
> I see a lot of advantages:
>
> * easier for the maintainer, I hate to create several directories
> for only one file
It's one bloody command!
> * no problems with file names
Well you have a point there, possible conflict of namespace in the
/usr/share/... area. If the files had to be the package name, then
that would take care of that issue ;).
> * it#s easier to support /usr/local/doc, relative links
We are compelled by policy not to create files under /usr/local, which
see. Even if not, I don't understand this.
> * you can move a whole diretory (include documents and our file)
> without changing "our file".
Things would defineatly break (i.e., the database in /var would now be
out of sync, i.e., look in the wrong place).
> * you could include the file very easy in a tar archive
What tar file? What's the point of shlepping around .dhelp or
.docbase or whatever files anyhow if they're not going to be
registered and noticed properly (i.e., no preinst).
> * maybe better, if you mount /usr/doc via NFS
Not thought thru; NFS wouldn't necessarily work w/o the backing of the
document indexing located in /var...
I'm sorry, but all these reasons of things you want to do seem to me
to be more reasons *not* to put files in /usr/doc, since moving the
registration files around at random is surely going to start breaking
things.
> If your#re for example upstream and Debian maintainer of a HTML document,
> you can ship "our file" in your tar archive. I don#t like files that have
> to be installed in special directories.
Well my feeling is that you don't like having to say
install -d debian/tmp/usr/share/doc-base
in your rules file and all reasons boil down to that. Which I can
sympathize with, although it doesn't convince me.
Anyone else have an opinion on the /usr/share/ vs. /usr/doc
debate here?
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: