[pre-GR] Requirements for usrmerge
Here's the first draft of the GR proposal.
Please review, and help me reword/derant!
================================================================
Over seven years ago, we were proposed with usrmerge, as a "never going
to become mandatory" simple script that can be "just installed and works".
Yet despite all the efforts, including a large number of developers who
have never volunteered for usrmerge work, it is still not ready. And it
is pushed through as if it were, ignoring trivially demonstrable problems.
There is a lot of misinformation, the prime one being that "all works ok"
and that "it's the dpkg maintainer blocking things". The list of issues
raised by Guillem is available:
https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge
https://wiki.debian.org/Teams/Dpkg/MergedUsr
and solutions were discussed many, many times. And Guillem did agree to
a plan, describing requirements for a patchset that would be acceptable
by him (see below). That would fix a good part of the issues, and is
conceptually simple.
Yet suddenly we are told that the problems don't matter, and so on.
The lack of apparent sky descending is mostly caused by the "temporary"
prohibition on moving files between aliased paths. Yet, without them
being dealt with, that prohibition would need to continue indefinitely.
Ie, if file A currently resides in /usr/bin and file B in /bin, they
must stay there until the end of times. All while breaking diverts,
alternatives, triggers, dpkg -S, repack, and so on if you happen to
type the supposedly equivalent path wrong.
We can sort of prevent moving by declaring it illegal (and dealing
with bugs inevitably happening by a maintainer doing so by mistake),
but that works only inside Debian archive. And, the vast majority
of our users are not Debian itself. Even most software, even most
_packaged_ software is not in the archive:
64% of popcon entries are not in Debian; a glance at popcon list
shows a lot of packaged differing only by version name -- but
a naive attempt at unifying versions reduced that only to 58%.
So the aliasing problems will continue biting us and our users, and
not just until Bookworm but permanently. These bugs could be fixed
(the agreed upon patchset goes most of the way), but after 7 years
with no working code the chances of seeing that w/o pressure are
about nil.
And that's not the only problem caused by usrmerge. Think about
pathname-based security policies. Symlink attacks when unpacking.
Commands like `which` giving random results. Etc.
But perhaps all the effort gets us something in the end? Here's the
biggest problem: there's still no answer WHY?!?.
First there came badness of split-usr. But that's about mounting
filesystems, not about their contents -- and that's been dealt with
a decade ago. And despite being consistently listed among reasons
for usrmerge is completely unrelated.
Then it was "so you can unify /usr between [virtual] machines".
That was a POC tried by Red Hat a decade ago, and it was abandoned
in favour of transparent stuff like reflinks, unionfs, LVM CoW,
ZFS, btrfs, shared qemu images and so on. And it wouldn't work
on Debian anyway because unlike them we rely more on /etc and /var
(with content with wildly differing write patterns). This is
again not a reason "for".
Then, "it's because Solaris has done so". Newsflash: Solaris is
long since dead, development crew having been laid of in 2017 and
only a stub team feigning maintenance so those "won't migrate for
a decade" customers continue paying; same as the rest of HP-UXes
AIXes OpenServers of the world.
Now the reason is "because Red Hat". And it turns out Red Hat
is following the well-trodden path: massive loss of market share,
being bought out (Oracle vs IBM), closing off its free edition
(OpenSolaris vs Centos), hiring freeze. Even a few years ago
everyone in The Enterprise™® used RH/Centos 6 or 7 (when 8 was out
for a while...), today they all ask Debian/Ubuntu questions.
I do hope that Red Hat survives (most of software whose development
they for is good), but I don't think following them is wise.
So let's see who followed and who not; I'm taking derivatives
together with their parent as otherwise we have >10k distributions
to count.
* Red Hat (Fedora, Rocky/Alma, Oracle Unbreakable, ...)
* Suse deserves a notion as while a Red Hat derivative, they put
some good work into the base system
* Arch
Who's on the fence:
* Debian
* Ubuntu (usrmerge only, but being based on Debian they use what we
support)
Who has explicitely unsupported variant:
* Gentoo (with a non-default init only)
Who has no usrmerge at all:
* Slackware
* OpenBSD / NetBSD / FreeBSD
...
Who has the reverse:
* GNU Hurd (/usr → /)
Obviously these trees have different sizes, but these days an "active
Linux distribution" is a near-synonym of "Debian derivative".
So if, despite the claims that "most distributions have switched",
most have not -- why would following Red Hat specifically be that
important?
In other words: much pain, questionable benefit.
So what can we do? Certainly it's bad to continue to support both
schemes, we need to pick one. But, we currently support both, and the
count of systems on merged-vs-unmerged state hardly matters -- it's
whether the code is done, and how much effort it would cost us to
write it.
At this point, I say: enough. If during seven years we had core bugs
unfixed and all code produced were transition scripts, there's no
point wasting more time. Otherwise it's one big sunk cost fallacy.
I thus propose the following statement:
============
The Debian project refuses to override the dpkg maintainer.
There shall be no enablement of usrmerge until the following conditions
are met:
* the proponents provide a patchset that fixes aliasing bugs in dpkg
according to the plan previously agreed with Guillem: that is, a
configurable set of aliased paths are used to redirect writes.
During a deletion or a query, both variants of an alias are checked,
and so on, with adequate testing of conceivable cases.
Such a patchset must be of quality acceptable to the dpkg maintainer;
alternate solutions may be negotiated if approved by the latter
* once such a patchset is sustantially ready, the proponents shall
provide a detailed analysis of costs and benefits. The "costs" are
mostly reported problems -- at least the issues listed on Team/Dpkg
wiki need a response such as "this now works" (or why not).
As for "benefits", we request that claims debunked during the GR
discussion don't get repeated.
Deadlines:
* if by the start of Bookworm freeze dpkg is not fixed, debootstrap
shall default to --no-merged-usr (that's already the case for
cdebootstrap and mmdebstrap)
* if such a patchset is not ready for Trixie, existing aliased-dirs
installs will be migrated to an alternate scheme, be it usr-merged
in some way or not, to be decided later
In the case of the dpkg maintainer not accepting a clearly working
patchset, or someone in a position of power tries to force the
maintainer to non-voluntarily step down, [HOW TO DECIDE?]
============
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Bestest pickup line:
⢿⡄⠘⠷⠚⠋⠀ "Cutie, your name must be Suicide, cuz I think of you every day."
⠈⠳⣄⠀⠀⠀⠀
Reply to: