Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On 5 Aug 1999, Chris Waters wrote:
> Santiago Vila <sanvila@unex.es> writes:
>
> > I think there are several wrong assumptions here:
>
> Hmm, maybe so. Or at least arguable points. But these were all in
> the preamble, not in the proposal itself. The proposal was a pretty
> simple statement. :-)
I have a proposal too, which is even more simple:
* Keep things as they are. Modify debhelper and debmake so that
they follow current policy. Start converting packages right now.
Since, according to debhelper author, there are many people using debhelper,
there will be a whole lot of packages converted to FHS at release time.
I can't give you any figures, but I'm sure if we stop this somewhat
fruitless debate now and start converting packages, we will finish the FHS
transition very soon.
Perhaps potato will be only 80% FHS at release time, I don't know, but the
real benefit will be that the distribution after potato will be much more
FHS-compliant than it would if this proposal is accepted.
Fortunately, I don't need a proposal or a preamble for this, because it
has been already made policy. BTW: we did it policy by following the
policy procedure, which was designed to achieve things by consensus.
> > 1. "Today is not long before a release".
>
> > The fact is that *nobody* knows when we will get rid of the 200
> > important bugs, so saying "at this point" is not very meaningful.
>
> Yes, very true, I frequently use this argument myself. That doesn't
> mean I can't *hope*! :-)
So, if we don't know for sure when we will release potato, we should not
base our decisions on the release date.
We want to be FHS compliant in the long term, and, in some sense, we would
like to be FHS-compliant better sooner than later. Well, if we do not
base our decisions on the release date the best thing to do would be to
start converting packages right now, regardless of potato's release date.
> > 2. We would have to delay a release to meet a "release goal".
>
> This was followed by an "or" clause. I know we don't have release
> goals, but the alterative, if we do nothing now, is to have an
> inconsistent system.
I do not agree here with your use of the word "inconsistent".
Either having packages using /usr/share/doc and /usr/doc at the same time
is bad or it is not. If it is "bad", we should make /usr/share/doc a
release goal, not postpone it even more. If it is not so "bad", we should
keep policy as it is now, so that at release time we have the greatest
number possible of converted packages.
> > 3. A system having packages using /usr/doc and /usr/share/doc is
> > "inconsistent" and this should be avoided by all means.
>
> Not "by all means". I prefer an inconsistent system to the mandatory
> symlink scheme (though not by a lot). Remember, you and I were formal
> objectors one and two to the symlink proposal. :-)
Well, I consider the symlink proposal an extremely bad idea, and
this proposal is perhaps just "bad".
I also prefer this proposal to the mandatory symlink scheme, but
this does not mean I have to be happy with it.
> > This mix of /usr/share/doc and /usr/doc will happen sooner or
> > later.
>
> But not necessarily in a stable system, if we do it right. We may not
> achieve that goal. We may not get all the packages updated before
> Woody's release. Ok, we'll burn that bridge as we cross it. But
> we've managed to get nearly every package rebuilt in both of the
> *last* two release cycles, I don't see why we would suddenly lose that
> ability.
Please note that libc6 was a release goal for hamm, so it is not a miracle
that we managed to rebuild almost all packages. We had to do it.
Anyway, if you are convinced that we can rebuilt every package, we should
start now and *try* to achieve that sort-of-goal for potato, not postpone
it even more.
> I'm not offering any guarantees here, but I think this is our best
> shot to do it right.
>
> > If we delay the move to potato+1 it is almost sure that it will
> > not be finished at release time either, because there are too
> > many packages in the distribution.
>
> We managed to get hamm and slink out the door, despite a need to
> recompile all the binaries. I don't see why this would suddenly
> change now.
Please note also that there was no need to recompile all the binaries for
slink, only those who depended on obsolete libraries, and even in that
case this is not usually considered an "important" bug.
> [...]
>
> > How can you measure the annoyance?
> > [ I'm curious about this ].
>
> I can't make a hard and fast measurement, obviously, which is why I
> said "probably", but I know that several users have *already* objected
> to the idea of leaving things they are now (some have even made idle
> threats to switch distros, not that I care about such "threats", but
> still...). And *speaking as a user*, I can say that I already find it
> annoying.
Well, I actually did some sort of measurement: I tried to imagine how
do users spend their time when using documentation.
I think that an ordinary user spends most of the time reading
documentation, not looking for it. I can understand the annoyance of
looking for something in /usr/doc/foo and then realizing it is actually in
/usr/share/doc/foo. However, once you know the right directory you usually
spend the remaining time reading documentation, and as far as reading is
concerned, the content is the same.
So, in my opinion, the annoyance is quite low and negligible, and it does
not justify postponing the move to /usr/share/doc.
> > Are we going to take a step back because of something we can't measure?
>
> I can measure my own personal annoyance with this inconsistency, and
> it's fairly high. I think that many other people agree, judging by
> the posts I've seen.
The funny thing about this is that we have already *two*
difficult-to-measure things as arguments in favour of this proposal:
1. The release date for potato ("since we will not be able to do it in
time we will not even try").
2. The comparative annoyance the mix will produce to our users.
("Since it will annoy everybody, we will not do it").
I think we should be serious, and base our decisions on technical reasons,
not on subjective reasons.
> [...]
> in the long run. Yes, it's bit a gamble, and I don't want to hide
> that. I think it may also be our best shot, possibly our only one, at
> producing clean *stable* distributions both now and in the long run.
> I think it's a gamble well worth taking.
Your proposal would probably make potato very "nice", but will delay
the FHS conversion by *several* months. I see this as a bad thing.
In fact I see it bad enough to formally object to it.
> [...]
> Perhaps we should poll the users....
Perhaps (this is not a bad idea), but in such case we should tell them the
truth:
1. We don't know when we will release potato.
2. If we forbid /usr/share/doc now, we will not know when we will release
the first distribution which is fully FHS-compliant.
You (and other people) seem to be sure that potato will *not* be
reasonably FHS-compliant if we keep current policy and *quite* sure that
woody (or whatever potato+1 is called) *will* be if we accept your
proposal. Well, I can't explain this.
> And hey, when it comes down to it, this is just a proposal. My
> *primary* goal is to give the tech committee something else to
> consider if Manoj *does* send his proposal to them! :-)
As such, this proposal is excellent, we agree on this :-)
I hope the tech committee does also consider the current status as one
more option (i.e. that we do nothing special about the transition
from /usr/doc to /usr/share/doc).
> I think that with the number of seconds I've recieved (thanks guys!),
> this proposal is now too strong to ignore, even if it doesn't make it
> through the debates here. Which is really what I wanted. Formally
> object if you must -- I don't think it'll win you any friends, but it
> won't stop this proposal from filling *my* goals for it! :-)
Fine. I formally object to this proposal.
I object for the reasons above stated, amd because I think we have much
better things to do with our time than:
* Converting packages twice (one for FHS compliance, another one for the
/usr/share/doc directory).
* Guessing the release date of potato (is someone here really able
to guess the future?).
* Declaring that a package which is fully FHS-compliant violates policy.
In summary:
Either the mix of /usr/share/doc and /usr/doc is bad enough to not make
/usr/share/doc a release goal, or it is not bad enough. If it is bad
enough we should make /usr/share/doc a release goal. If it is not bad
enough, we should allow /usr/share/doc in potato, as it says policy
currently.
Thanks.
--
"2b8f8ce14304b84b9789bdb7f8ee3071" (a truly random sig)
Reply to: