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." ⠈⠳⣄⠀⠀⠀⠀
