/usr/share/doc vs. /usr/doc transition, debate reopened
Manoj Srivastava <srivasta@debian.org> writes:
> [I think, since this is a dead proposal, there is not much
> point carrying out what has become a nit picking discussion
If an attempt is going to be made to get the tech committee to mandate
this proposal over the objections of many developers, then I think the
discussion is not so dead after all.
> 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.
Which is the whole reason I objected! We have not, IMO, spent enough
time considering the options.
Yes, I know, sometimes we debate things too much. But on the whole, I
think the distribution is better for it! And, anyway, I disagree that
this is such a case. I came up with the skeleton for a couple of
proposals during this discussion, and we haven't taken *any* time to
look at those ideas yet.
As I said originally, if we can't come up with a better proposal (and
I now think there's a good chance we can), then I'd withdraw my
objection. Which may not help, since others objected, but it's still
something I wish you'd keep in mind.
In fact, since the proposal is dead (at least for now), the BEST thing
we can do at this point is start debating the alternatives as quickly
as possible! Otherwise we're stuck with a partial migration, which I
agree is ugly and undesirable, or a political end-run around the
normal policy mechanisms, which could stir up a shitstorm.
So, first the lesser of my two current ideas:
> 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
So we make it a script. Problem solved. (With error checking and
special cases, a script is probably a better approach anyway; the
above was merely intended as a proof-of-concept example.)
> 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]
Very true. There are always tradeoffs -- in this case, we gain
flexibility.
> 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? [...]
> Vapourware. This is not a workable proposal, IMHO
Vapourware? I just presented a skeleton of working code!! That is
NOT vapourware. And far from not being workable, it IS working, right
here, right now! Granted, it's far from *polished*, but it was also
about five minutes work! Give me a day or two, and I could present
something much more solid. (But I won't bother unless we decide this
is the approach we want to take.)
In any case, this was just ONE proposal. Not necessarily the best,
but not necessarily the worst. This is *NOT* the proposal I would
currently support, but it's an idea I wouldn't *completely* reject
either, if others liked it. I'm just throwing out ideas here, to try
to open up the debate.
> 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.
So we amend policy! That's what you were trying to do. And, BTW, the
symlinks are *not* FHS-compliant; they are, at best, FHS-compatible.
And not even that until all packages are using them. Which leads
directly to my earlier comment:
> 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?
I *still* think this is the best approach, and I'd like to make a
formal proposal along these lines, but I still have a few questions
about the best thing to do *after* potato is released. We could
either, a) begin a wholesale migration, aiming for FHS *compliance* in
Woody (I think we can do it), or b) go with the symlink proposal (and
mere FHS-compatibility) *at that time*.
OTOH, I don't think the multiple locations proposal is without merit
either, and I wouldn't mind seeing some discussion of that.
In point of fact, I don't think the symlink proposal is without
merit either. I just think it's badly timed, and not *necessarily*
the best proposal.
cheers
--
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: