Bug#69311: PROPOSAL] Finishing the /usr/doc -> /usr/share/doc transition.
On 23 Aug 2000, Manoj Srivastava wrote:
> > Woody shall have a full /usr/share/doc/ when released, while
> > allowing for partial upgrades from potato all the way, under the
> > plan.
On Thu, Aug 24, 2000 at 02:03:06PM +0200, Santiago Vila wrote:
> The "partial upgrades" issue is a myth. As I said, we have never
> guaranteed that *every* conceivable partial upgrade will work (because
> of versioned dependencies on newer packages). Very often, upgrading a
> package forces the upgrade of some others, and this is not considered
> as a bug or a deficiency of the system. Do we agree on this?
I disagree that the "partial upgrades" issue is a myth. Your "proof"
of this "myth" only has relevance where explicit dependencies (or
conflicts) exist.
[Aside: we're going to be using "partial upgrades" extensively during
the development phase of Woody. Introducing breakage would slow down
the release of Woody, and would interfere with proper testing of the
rest of the system.]
Also, introducing dependencies to manage the /usr/doc/ transition would
add a whole new suite of problems. If you care to understand those
issues, you might want to take a look at the debian-ctte traffic from
a year ago.
> > I think this is not the time to start getting impatient, and
> > saying that 79% completion is as good as done. (one or two percent,
> > perhaps, but 21% -- I don't think so)
>
> I'm not saying 79% is as good as 100%, I'm saying that a 79% of
> converted packages after the upgrade from slink to potato is good
> enough to consider a modification of the original plan, by letting the
> two transitions which still have to be done to overlap:
>
> 1. Packages use /usr/share/doc. This transition is 79% complete. We
> expect it to be complete by the time woody is released.
>
> 2. Packages do not create any symlinks in /usr/doc.
> This transition is 0% complete, because it has not even started.
What I don't get is why you're so eager to break things. What
problem do we solve by tossing those symlinks?
Please don't say FHS compliance.
Or, if FHS compliance is the *only* benefit we get (and no actual
problems -- are solved), please provide a list of all the issues that
have to be solved for FHS compatability and FHS compliance. Then we
can talk about how reasonable it is to achieve FHS compliance for Woody.
If you don't care enough about the FHS compliance to come up with a
complete list of issues then I don't think you really care about FHS
compliance for Woody.
> I think many users will appreciate that we start the second transition
> now, most of them already know that an arbitrary mix of packages from
> stable and unstable is not always guaranteed to be problem-free, and
> I'm sure that most of them want to get rid of the symlinks as soon as
> possible.
Users could care less about this second transition. It doesn't solve
any real problems. The second transition just gets rid of a minor
level of backwards compatability, which makes things slightly cleaner
for us developers.
> In either case I would like ask some important questions:
>
> When the Technical Committee made their decision, was there a proposal
> to have symlinks in potato and no symlinks in woody which they could
> have chosen, or the only option in the voting ballot involving
> symlinks was what we call the "original plan"?
Why is this an important question? The entire proceedings of the
technical committee are available in the mailing list archives.
As it happens there were a variety of proposals on the ballot.
The most important lesson to learn from those proceedings, however,
was that THE TECHNICAL COMMITTEE SHOULD NEVER HAVE BEEN PRESENTED WITH
THIS PROBLEM IN THE FIRST PLACE. The /usr/doc/ problem should never
have happened.
The only reason that this issue got dumped on the Technical Committee was:
some people implemented the crazy idea that breaking things in the name
of standards compliance was more important than having a decent release.
> If, as I think, the second is true, I could say that what they
> *really* decided (since the T.C. does not really decide anything
> but from a set of multiple choices) was to use symlinks during the
> transition period. Let's say that the policy group decides that we
> want potato to be the only "transition distribution", would this
> contradict a decision by the T.C. and would be void?
If the policy group makes a decision to introduce breakage into debian
systems, would it be good or bad if such a decision were void?
> In other words: Could it be that this may only be solved by a General
> Resolution?
Whatever.
--
Raul
Reply to: