Re: usrmerge -- plan B?
Russ Allbery writes ("Re: usrmerge -- plan B?"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> >> "We ran into some unanticipated issues when we usrmerged our build
> >> systems, and we think the way to fix that is to force merge every one
> >> of our users' systems."
>
> > That does seem to be the position that is being advanced.
>
> I think this is an unfair characterization of the thread, and adds
> considerably more heat than light.
I'm afraid I see it as totally fair. (And I do very much hesitate to
disagree with you since you are usually right about everything.)
> We ran into unanticipated problems *with supporting full portability of
> packages between usrmerged systems and non-usrmerged systems*.
It was very clear that what was proposed, some months ago, was
*optional* usrmerge, which necessarily involves cross-compatibility.
It was on that basis that there were few objections. Thus the
original design promise from usrmerge proponents, when these changes
were last discussed here, was indeed full portability of packages.
(Whether the usrmerge proponents realised that or not.)
> (And I'm not sure the problems were really that unanticipated --
> that problem is hard.)
No doubt there were misgivings in several quarters. I had my own
misgivings. But I kept them to myself, in a spirit of not picking an
unnecessary fight. After all if something is optional then I can just
not opt in. If someone wants to do something that might break their
system then why not let them ? They can keep all the pieces.
But when I said `unanticipated issues' I meant, of course,
unanticipated by the usrmerge designers and implementers. Yes,
those problems were unanticipated problems *of full portability*
rather than of usrmerge as an abstract principle. But the usrmerge
designers and implementers either (i) did not realise that their
actions depended on full portability, or (ii) did not realise how hard
it would be. That's why there was no plan for how to achieve it.
My position as a usrmerge sceptic, of letting them get on with doing
their thing, now seems to have been unwise. The idea that it would be
optional mutated, without proper discussion, and without a transition
plan, into it being the default for new installs.
And now there are serious suggestions that to solve this lack of
foresight, lack of proper planning, lack of proper consultation, and
lack of attention to detail, we should press ahead even faster and
make the new scheme mandatory ?
On a narrow technical level I can see why that is attractive. But in
the wider world, when a particular project team has caused lossage due
to poor technical judgement, excessive haste, and at least a perceived
reluctance to accomodate feedback, it is rarely the right response to
be *less* critical of their plans and recommendations, and push on
harder.
Especially if that risks alienating objectors who will rightly feel
that they would have predicted a mess, if anyone had been prepared to
listen to them.
I'm sorry to have to put these things this way. This will no doubt
read as a criticism of the people rather than of the code, which is
difficult and undesirable. But, whether the problems are cultural, or
whatever, the dispute here is not only about technical details.
We cannot resolve the risk/reward tradeoff of usrmerge with a
definitely correct answer because we do not have, and will never have,
all the necessary information. We cannot know how many systems in the
field would break from a forced usrmerge; even if we were to go ahead
with that we would probably never know the real cost.
Necessarily this is going to be a matter of judgement and guesswork.
The question then: whose judgement and guesswork ?
I would like to contrast the approach here to the way that the
AppArmor team have conducted their transition. Throughout they have
been alert to problems; sought feedback; avoided commitment; and
generally brought the vast majority of the Debian community along with
them. They have gained not only rough consensus but what looks like
real consent (insofar as such a thing might be possible collectively).
On the narrower question it must surely be obvious that it is far too
late to try to do a forced usrmerge of all systems in buster.
Certainly we should not be discussing forced usrmerge as anything but
a theoretical option, given that there is not even any transition plan
for it and the buster transition freeze is weeks away.
The default should be changed back not just in our buildds but also
for ordinary new installs. usrmerge proponents can use the time
between now and the release of buster to refine their understanding of
the issues, do the necessary research, and write a transition plan.
We can then have this discussion again early in the bullseye release
cycle. If we must.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: