>>>>> "Zack" == Zack Weinberg <z...@owlfolio.org> writes:
Zack> On Wed, Nov 17, 2021, at 1:37 PM, Sam Hartman wrote:
>>>>>>> "Zack" == Zack Weinberg <z...@owlfolio.org> writes:
Zack> Therefore: either someone fixes the bug, or the transition
Zack> will have to be canceled. It appears to me that the tech ctte
Zack> agrees with all of this.
>>
>> There's a third option. We sit around in the state where /bin is
>> a symlink, but where you cannot move files to /usr paths in the
>> 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, as
Zack> packages are rebuilt on systems that now have /bin a symlink.
I don't like that outcome either.
I think that we have reasonable migigations for the specific problem you
describe.
In particular, we do as I understand it have QA plans to build both with
merged /usr and without prior to bookworm to catch problems like the
ones you describe.
After bookworm releases it's totally fine if programs reference
filesystem paths like /usr/bin/bash, so long as they don't move where
things get installed.
So, while I agree with you getting stuck in the middle is not a good
place,
I don't think it happens to suffer from the problems you describe.
>> I.E. I don't think the transition is going to get canceled; we're
>> too far down that path.
Zack> *Are* we? It seems to me that we could still, at this point,
Zack> pull usrmerge from testing and stable, push point updates to
Zack> the installers for all supported releases to flip the default
Zack> back to non-merged /usr, and advise the installed base to run
Zack> dpkg-fsys-usrunmess before their next apt upgrade.
That seems crazy to me: dpkg-fsys-usrunmess has almost certainly
involved less testing than usrmerge. Talk about not having people to do
the work: I don't think we would find people to do enough testing to
validate that was a reasonable thing to do. But also, the usrmerge
proponents get most of what they wanted even if we're stuck in the
middle. If you want a minimal root because you care about containers,
ostrees, and the like, you don't care that much where the package
database thinks files are being installed.
You've been working on this for years and you've gotten most of what you
hoped for.
You're going to fight really hard if someone tries to take that away.
You can easily fight hard enough to make that cost much higher than the
cost of fixing dpkg.
And you can present a reasonably looking political front: hey, we've
been working on this for years, the TC made a decision, the TC later
gave advice, we're basically just done except for this one dpkg bug.
Backing out is insane; just fix dpkg.
I want to reiterate that the initial process surrounding usrmerge was
horrible.
The dpkg maintainer had what turned out to be legitimate concerns that
were not reasonably addressed.
I think that's in part because they were presented poorly and in part
because people didn't want to hear them.
That's a real process failure.
We should learn from that mistake and do better in the future.
We don't have the political will to unwind years of work because we made
that process error, and I don't think it would be a good idea to do so
even if we did.
I do think we should be careful to be better about listening to each
other in the future.
We don't want a community where you can get your way by ignoring
legitimate objections.
I think people on both sides were unwilling to listen to each other.
And yes, if the dpkg maintainer had asked for usrmerge to block on dpkg
gaining support for aliasing, and if that had been done around the time
it was proposed to change the default for debootstrap, we as a project
should have listened.
That's not what happened though.
The dpkg maintainer refused to consider the usrmerge approach that the
usrmerge proponents wanted.
He proposed a different scheme that didn't actually meet the needs of
the usrmerge proponents.
He was unwilling to take the time to understand why his proposal didn't
meet other people's needs.
And yes, the usrmerge proponents (and especially the TC) should have
worked harder to understand the actual underlying objections.
So, there's a huge chunk of ways we could improve to go around--enough
for everyone involved.
But reliving past battles as anythying other than a way to do better in
the future will drag us down.
--Sam
signature.asc
Description: PGP signature
