Re: merged /usr vs. symlink farms
Hi,
On 21.08.21 19:47, Luca Boccassi wrote:
By all means, go and fix it, make it a top priority for dpkg to sort
out, all hands on deck, whatever needed - but to demand the entire
project has to stand still, and to de-facto derail the effort put in to
catch up with the rest of the world by imposing an unworkable,
demonstrably failed solution (symlinks farm) to work around a dpkg bug
instead of fixing it internally, to me does not seem acceptable in any
way, shape or form without some real, serious evidence that the sky has
indeed fallen.
There are two issues here: dpkg not handling certain corner cases, and
the usemerge package modifying the file system, bypassing dpkg.
The latter is what brought us into a situation where it is no longer
safe to move files between packages and between aliased directories in
the same upgrade, and because users will be expected to upgrade in a
single step between stable releases, that means these two types of
changes are mutually exclusive for the entire release cycle.
This happened precisely because people "put in the effort" to implement
this change without coordinating. This thing derailed on its own, and
accusing the people pointing that out of ill will is not going to fix that.
The fact that the sky has not yet fallen is not a reason for inaction,
but instead gives us the breathing room to implement a proper solution
instead of another hack that will add yet another possible upgrade
scenario we have to anticipate in the future.
We already have inconsistent package builds depending on whether a
package was built on a pre- or post-transition autobuilder, with the
exact same packages installed otherwise.
We have no piuparts test coverage for these scenarios, we have no QA
tools to verify that installing the new packages will always lead to
predictable outcomes no matter in which order you install them in --
such tools were never necessary before as dpkg resolves these problems
in a deterministic manner provided its installation database is
consistent with reality.
This is the situation we're in: the millions of systems out there work,
but we cannot guarantee that they will continue to work through the next
update because the QA infrastructure now has massive blind spots. This
is what needs to be fixed before further progress can be made.
If the bookworm upgrade does break systems on upgrade, then the sky will
indeed have fallen, only then it will be too late to do anything about it.
"It works for me" is anecdote, bugs count is not, it is a key metric of
this industry, I am quite surprised this needs to be specified. It's
how we decide whether a release is ready or not.
I see two problems here:
First, we're not the "industry." We're a Free Software movement. The
industry just happens to embrace us at the moment.
Second, I wonder why it doesn't give you pause if a group of senior
software people that uses a particular metric in one instance suddenly
seems to be utterly unaware of its existence in another.
What you call analytical
evidence on the other hand is a fancy word for "opinion".
Analytical evidence happens when you read the dpkg source code and the
usrmerge perl script and find a glaring obvious problem in the way they
interact, then construct a simple adversarial example in 11 lines of
text and two dpkg-deb calls and verify that it indeed loses files.
The scenario I posted will apply to any systemd package split between
bullseye and bookworm. If systemd moves unit files to /usr, then it
cannot move these to another package for the entirety of the release, or
risk the units disappearing on upgrade. It also applies to kernel module
and firmware packages, and several core system utilities.
We got lucky with the "which" command as that was in /usr already.
Opinions are
useful and interesting and important, but saying "everything is broken"
when there is a surprising lack of evidence of that being the case, is
not very useful or constructive.
Absence of evidence is not evidence of absence.
Simon
Reply to: