Re: merged-/usr transition: debconf or not?
>>>>>> "Sam" == Sam Hartman <hartmans@debian.org> wrote:
>>>>>> "Zack" == Zack Weinberg <zack@owlfolio.org> writes:
Sam> There's a third option. We sit around in the state where /bin is
Sam> a symlink, but where you cannot move files to /usr paths in the
Sam> package system until the bug is fixed.
Zack> I guess that is a potential outcome. In a sense we are
Zack> already in that state, given the installed base of systems
Zack> where /bin is already a symlink.
Zack> I don't *like* that outcome; I think it's asking for lots and
Zack> lots of accidental breakage in unstable post-bookworm.
Sam> I don't like that outcome either.
Sam> I think that we have reasonable mitigations for the specific problem you
Sam> describe.
Sam> In particular, we do as I understand it have QA plans to build both with
Sam> merged /usr and without prior to bookworm to catch problems like the
Sam> ones you describe.
Sam> After bookworm releases it's totally fine if programs reference
Sam> filesystem paths like /usr/bin/bash, so long as they don't move where
Sam> things get installed.
I don't think that will mitigate the problem. I think that post-bookworm,
packages like coreutils and libc6 are going to notice, in their upstream
configure scripts, that /bin etc are symlinks into /usr, and start installing
stuff that used to be in / into /usr. Maintainers are going to need to take
positive action to _prevent_ the move, and there will no longer be automation
to detect that files have moved.
Sam> I.E. I don't think the transition is going to get canceled; we're
Sam> too far down that path.
Zack> *Are* we? It seems to me that we could still, at this point,
Zack> [roll back the transition]
Sam> I don't think we would find people to do enough testing to
Sam> validate that was a reasonable thing to do. But also, the usrmerge
Sam> proponents get most of what they wanted even if we're stuck in the
Sam> middle.
That is exactly why I think a rollback should not be taken off the table:
it is very, very bad if the usrmerge proponents get most of what they want
while the rest of the project is left to clean up their mess. The project
cannot afford to reward such misbehavior. I honestly think the social
fallout of allowing that to happen would be *worse* than the social and
technical fallout of forcing a rollback through.
...
Sam> I want to reiterate that the initial process surrounding usrmerge was
Sam> horrible. The dpkg maintainer had what turned out to be legitimate
Sam> concerns that were not reasonably addressed. I think that's in part
Sam> because they were presented poorly and in part because people didn't
Sam> want to hear them. That's a real process failure.
...
Sam> I think people on both sides were unwilling to listen to each other.
I'm an outside observer and I have not followed this argument closely from
the beginning, but my perception of it is much more one-sided than you are
making it out to be. This is what _I_ saw:
- usrmerge was deployed to unstable in late 2014. It's not clear to me
how much testing it got in 2015.
- Reports of it causing problems for dpkg started to appear in early 2016
(e.g. #810499). These seem to have been addressed civilly, but even then
a "well it works for _me_ so :shrug:" attitude from the merged-/usr
proponents is evident in the bug logs.
- The dpkg maintainer filed a severity:serious bug on usrmerge in late
2016 (#848622), saying that it breaks dpkg -S. This is the earliest
instance I can find of Marco in particular overtly blowing off a bug
report that he didn't think was significant ("Over one year of
experience with merged-/usr systems has not exposed any failures",
which is an invalid argument). This bug is also significant in
hindsight because, although not described as such, it appears to me
to have the same root cause as the file lossage on upgrade that you
and I, at least, agree is severity:critical.
- Over the next, um, *five years*, Marco continued to ignore or reject
Guillem's attempts to get him to take problems seriously that were
caused by usrmerge rendering the dpkg database inconsistent with the
file system.
- Marco also reacted hostilely to concerns raised by others, e.g.
Adrian Bunk (#863269).
- Guillem, for his part, has displayed far more patience than I would
have in his situation, repeatedly attempting to explain why there is
a serious problem, offering concrete solutions - that they may not be
practical is not the point; he's done more work toward that end than
anyone else - and never, that I have seen, losing his temper.
At the same time, he has said in so many words that this has caused
him to become burnt out on Debian in general and dpkg maintenance in
particular.
There's no "both sides were unwilling to listen" when all one side is
bringing to the table is "there's no problem, your concerns are bullshit"
(the word "bullshit" is actually used in #863269).
Maybe it was not obvious to anyone in 2016 that the package database
being inconsistent with the filesystem could cause actual data loss.
However, I think it was the responsibility of the developers of usrmerge
to find out how bad that problem actually was, rather than dismissing it.
And, as it has proven to be a genuinely critical problem, it is also their
responsibility to fix it, per the 'no one can be forced to do anything' rule.
Sam> We don't want a community where you can get your way by ignoring
Sam> legitimate objections.
Exactly! Taking a rollback off the table at present, *rewards* the bad
behavior of the merged-/usr proponents, and demonstrates to the community
that making life miserable for one's fellow DDs is a *successful* strategy
for getting one's way. That can't be allowed to happen. There need to be
consequences for burning people out - such as "either fix the mess you created
or see your work to date undone".
zw
Reply to: