Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
[a second followup to cover one point more accurately, and to add some
details to another]
Manoj Srivastava <srivasta@debian.org> writes:
> I have a couple of things to say about this proposal. I think
> that we have a bad track record when it comes to merely deferring the
> issue until a latter date
This proposal defers nothing. It merely mandates a *delay* for the
transition. Granted, it does leave room for someone to come up with a
"deus ex machina" solution to the migration (i.e. a working patch to
dpkg that magically fixes everything, and which IWJ loves), but it
doesn't rely on any such thing. It's very simple. Potato continues
to use /usr/doc, Woody and beyond use /usr/share/doc. No fuss, no muss.
> Secondly, I think that the policy should not hard code release
> names
I would call this a serious flaw in policy then. I think we NEED a
way to say, "these are the rules for release "X", these are the rules
to follow subsequently." Ideally, I think we'd have a strategy
document that takes precedence over policy, but that's a fairly major
proposal, one that I'm a long, *long* way from proposing formally. :-)
The way this was handled in the symlink proposal (leaving the cleanup
to an unspecified future policy change which may or may not ever
happen) strikes me as a *really* awful way to handle this. Far better
to just allow the proposal to specify which parts apply to which
releases if it's important to do so (as it is with these proposals).
> At a latter date, policy can be changed to reflect that the move is kosher.
I think this is much worse than "hard coding" release names in policy.
Though I agree that neither is *ideal*. But there's only so much that
can be done today. Either we institute temporary policy with *no*
markings and *assume*[1] that we'll fix it later, or we clearly mark
it as temporary policy when we all know that it is temporary policy.
I think the latter is *far* preferable.
[1] and you know what "they" say about assumptions....
--
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: