Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Manoj Srivastava <srivasta@debian.org> writes:
> The fact that a single probe into the location derived using
> the pacjage name is no longe guaranteed to work is indeed a technical
> fault.
First of all, this hardly the only proposal which could adress that
concern (see other proposals below) and second of all, it's not
necessarily true.
Off the cuff, no error checking:
docdir() {
dirname $(grep "/doc/$1/copyright\$" /var/lib/dpkg/info/$1.list")
}
cddoc() {
cd $(docdir $1)
}
Now we're back to a single probe. We're just probing the database,
not the filesystem.
And this opens up new possibilities. What if we add better support
for multiple locations of "/usr/doc" type stuff in general? The local
sysadmin could suddenly create private packages to install in
/usr/local (including /usr/local/doc), safe from conflict with
whatever we might do, and not even notice. Third party vendors could
go wild in their little patches of /opt.
> Chris> And in any case, it's not one location vs. two. It's more
> Chris> like three or four vs. four or five. We have man pages, info
> Chris> files, built-in help systems, dwww and dhelp, oddballs like
> Chris> gnome-help, and, finally, as a point of last resort (at least
> Chris> for non-masochists), we have the all-too-often useless
> Chris> /usr/doc area.
> The only one in consideration here is the /usr/doc area.
No, the only area *you* are considering is /usr/doc. I am considering
the whole system. If we had all the documentation in one place and
one place alone, I would never have opposed this proposal in the first
place. Although, the more I ponder the situation, the more glad I am
that I did.
[symlink disk space]
> It is not, IMHO, a flaw. The Debian installation requires hard
> drive space is a requirement, not a flaw. Same here.
It is a flaw if the use of disk space is gratuitous and doesn't
provide enough benefit to justify its use.
> Chris> said that it was a technical flaw. Objecting that it's a
> Chris> minor flaw doesn't make it not a flaw.
> Calling a requirement a flaw does not make it a flaw either.
Calling it a requirement doesn't make it not a flaw either.
Frankly, this whole proposal smacks of panicked quick-hack to me, and
I don't think the situation is dire enough to justify panic; I see at
least two other viable short-term alternatives:
1) stick with /usr/doc till potato is out (I thought this was the
original plan), and
2) migrate packages willy-nilly, and support two locations as long
as we have to (obviously what some expected).
Personally, I still think 1) is the best choice. Potato is going to
be violating the FHS here, I think it's clear, why not just go ahead
and violate it good and hard? Stick with /usr/doc until we have a
stable release, and not waste time messing around with setting up all
these fancy symlinks yet. Then maybe we won't have to.
If we stick with /usr/doc, then long term (i.e. post-potato-release),
we again have several options:
a) this proposal (the "stop-gap")
b) willy-nilly (the "easy way")
c) accept multiple locations (the "hard way")
d) automated migration (the "deus ex machina")
e) the one I didn't think of ("Schroedinger's cat")
Despite your snide comments about debating this for decades, I think
that one of the things that makes Debian stand out is that we *do* try
to take the time to do things right. And that's why I'm dubious about
a stop-gap. I'm also concerned that we may be stuck with these
symlinks for much longer than we'd expected if we do use them. The
whole idea of a proposal that proposes a future proposal to fix the
existing proposal (your "policy 4.0.0") makes me very leery.
I think we need to make time our friend, not our enemy, on this one.
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: