Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
Hi,
[I think, since this is a dead proposal, there is not much
point carrying out what has become a nit picking discussion
about the nature of flaws and the meannig of requirements. As
usual, I think we have moved into one of our endless dabates
that lead to no action, and this line of action is doomed to
picayune nitpicking. I have nothing firther to say about
this.]
>>"Chris" == Chris Waters <xtifr@dsp.net> writes:
Chris> 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.
Chris> First of all, this hardly the only proposal which could adress
Chris> that
Your point? This is one of the few discussed so far that does.
Chris> concern (see other proposals below) and second of all, it's not
Chris> necessarily true.
Chris> Off the cuff, no error checking:
Chris> docdir() {
Chris> dirname $(grep "/doc/$1/copyright\$" /var/lib/dpkg/info/$1.list")
>>
Chris> cddoc() {
Chris> cd $(docdir $1)
Firstly, this has to be in every users environemnt, and thus
needs be written for all shells out there. So, taking an average of
2.57 users per system (I am making the figures up), with about 25%of
the 7million Linux boxes out there (let us round down to one
million), you wqant 2.5 million environments to be so
modifed. Brilliant.
Chris> Now we're back to a single probe. We're just probing the
Chris> database, not the filesystem.
Still does not answer less /usr/doc/<package>[TAB]
Chris> And this opens up new possibilities. What if we add better
Chris> support for multiple locations of "/usr/doc" type stuff in
Chris> general? The local sysadmin could suddenly create private
Chris> packages to install in /usr/local (including /usr/local/doc),
Chris> safe from conflict with whatever we might do, and not even
Chris> notice. Third party vendors could go wild in their little
Chris> patches of /opt.
Vapourware. This is not a workable proposal, IMHO
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.
Chris> No, the only area *you* are considering is /usr/doc. I am
Chris> considering the whole system. If we had all the documentation
Chris> in one place and one place alone, I would never have opposed
Chris> this proposal in the first place. Although, the more I ponder
Chris> the situation, the more glad I am that I did.
Actually, you are the one who expanded this. The proposal (and
not just I) concerned only /usr/doc, sionce we have other aspects of
the FHS transition underf control. You are the one who has widened it
to a blue sky project.
Chris> [symlink disk space]
>> It is not, IMHO, a flaw. The Debian installation requires hard
>> drive space is a requirement, not a flaw. Same here.
Chris> It is a flaw if the use of disk space is gratuitous and doesn't
Chris> provide enough benefit to justify its use.
gratuitous? Not enough benefit?
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.
Chris> Calling it a requirement doesn't make it not a flaw either.
I see. Word games.
Chris> Frankly, this whole proposal smacks of panicked quick-hack to me, and
Chris> I don't think the situation is dire enough to justify panic; I see at
Chris> least two other viable short-term alternatives:
Chris> 1) stick with /usr/doc till potato is out (I thought this was the
Chris> original plan), and
Too late. The FHS is now policy. I am not going to go into
freeze with policy violating packages. You can do as you wish.
Chris> 2) migrate packages willy-nilly, and support two locations as long
Chris> as we have to (obviously what some expected).
Chris> Personally, I still think 1) is the best choice. Potato is going to
Chris> be violating the FHS here, I think it's clear, why not just go ahead
Chris> and violate it good and hard? Stick with /usr/doc until we have a
Chris> stable release, and not waste time messing around with setting up all
Chris> these fancy symlinks yet. Then maybe we won't have to.
Chris> If we stick with /usr/doc, then long term (i.e. post-potato-release),
Chris> we again have several options:
Chris> a) this proposal (the "stop-gap")
Chris> b) willy-nilly (the "easy way")
Chris> c) accept multiple locations (the "hard way")
Chris> d) automated migration (the "deus ex machina")
Chris> e) the one I didn't think of ("Schroedinger's cat")
Chris> Despite your snide comments about debating this for decades, I think
Chris> that one of the things that makes Debian stand out is that we *do* try
Chris> to take the time to do things right. And that's why I'm dubious about
Chris> a stop-gap. I'm also concerned that we may be stuck with these
Chris> symlinks for much longer than we'd expected if we do use them. The
Chris> whole idea of a proposal that proposes a future proposal to fix the
Chris> existing proposal (your "policy 4.0.0") makes me very leery.
Chris> I think we need to make time our friend, not our enemy, on this one.
We are also known for debating things endlessly, and then ot
doing anything. I think this is the way we are going down.
manoj
--
To a Californian, all New Yorkers are cold; even in heat they rarely
go above fifty-eight degrees. If you collapse on a street in New
York, plan to spend a few days there. From "East vs. West: The War
Between the Coasts
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: