Just thought I'd forward this important message...


-------- Forwarded Message --------
Subject: What does /usr-merge an DEP-17 mean for derivatives?
Resent-Date: Mon,  4 Sep 2023 06:33:48 +0000 (UTC)
Resent-From: debian-derivatives@???
Date: Mon, 4 Sep 2023 08:33:05 +0200
From: Helmut Grohne <helmut@???>
To: derivatives@???
CC: Paride Legovini <paride@???>

Hi,

we've been discussion strategies on lifting the file move moratorium
added for the /usr-merge for a while and the currently favoured approach
is dubbed as DEP17[1]. During that discussion, a number of people have
raised the effects on Debian derivatives as a concern. As a consequence,
I am looking for a way to reach out to derivatives to help them ensure
that their derivative continues to work in the presence of DEP17 work.
Would someone be able to assist in that process of getting the message
out to affected derivatives?

Let me explain what changes we're up to and why it is important for
derivatives to act. The current DEP17 effectively proposes to move all
files from aliased directories in / to their physical counterparts below
/usr and employ a number of techniques to ensure that "nothing bad"
happens. That badness often arises from combining two packages in
unfortunate ways and we intend to address it only in so far as such a
combination actually exists. Since derivatives sometimes contain
packages not in Debian they may experience problems that remain
unaddressed in Debian even in packages that are included in Debian due
to the interaction with their added packages.

Most derivatives follow the aliasing layout that has become mandatory in
Debian bookworm. Even then, they face issues, because the chosen layout
violates some assumptions in dpkg. The resulting problems are described
in the DEP17 document. Thus far, the moratorium has prevent many of the
problems from happening. As we lift the moratorium, that will cease to
be the case. On Debian, we address this by monitoring the archive
contents for problems. I recommend that every derivative that adds
packages or restructures packages from Debian set up their own
monitoring infrastructure for detecting problems. I recognize that this
is a non-trivial amount of work, but I see little alternatives at this
time. There is a detection framework available at
https://salsa.debian.org/helmutg/dumat. I've run this on Ubuntu once and
added zstd support in the process. For Debian, I will publish results at
https://subdivi.de/~helmut/dumat.yaml. It does not need a beefy machine,
but it needs close mirror proximity. If you need support with this tool,
please open an issue in salsa.

There also seems to be a limited amount of derivatives that have not yet
adopted the aliasing layout that is mandatory since Debian bookworm. I
am not sure how and whether this layout can be kept alive. Derivatives
that use bookworm or later should carefully consider whether deviating
from Debian in this respect is worth the involved effort. As we
progress, it will no longer be a matter of keeping the usrmerge package
absent, because we intend base-files to actually contain the aliasing
links in its data.tar.

Please Cc me in replies.

Helmut

[1] https://salsa.debian.org/dep-team/deps/-/merge_requests/5
     rendered version: https://subdivi.de/~helmut/dep17.html

-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722