Re: /usr-merge: continuous archive analysis
On Wed, 12 Jul 2023 at 22:23:08 -0400, Theodore Ts'o wrote:
> On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote:
> > There is one major issue where I don't have a good answer:
> > bookworm-backports. When this originally surfaced, Luca Boccassi
> > suggested that we do not canonicalize in backports. That's easier said
> > than done as the support for split-/usr will soon vanish from packages...
>
> ... detect whetther it is being
> built on a distro version that might have split-/usr, or not
I think it's important that we be clear about what does and doesn't need
to be supported in each suite, because it's a bit confusing, and I think
I can already see some of that confusion in this thread.
For bullseye and older, there were two supported layouts, which we
could call split-/usr and merged-/usr. In both of these layouts, it was
the package's choice whether the canonical path for a "/usr-like" file
inside the package's data.tar.* is in /usr (like /usr/bin/env) or not
(like /bin/bash). In split-/usr, the physical path on disk matches the
path that dpkg considers to be canonical. In merged-/usr, the aliasing
symlinks like /bin -> usr/bin exist, so the physical path on disk is
always in /usr, regardless of whether the canonical path is.
For bookworm, as resolved in #978636, merged-/usr is officially the only
layout that is supported. However, as resolved in #994388, we recommend
that all packages in bookworm keep canonical paths in data.tar.* the
same as in bullseye, for example /bin/bash. What we are now doing is trying
to find a safe way to lift that restriction for trixie.
Also, as resolved in #994388, we expect packages in bookworm to work at
least minimally in a split-/usr environment, because the upgrade from
bullseye to bookworm happens in an unspecified order and the system
should work (at least well enough for recovery) at all points through
the upgrade. In an effort to make sure that still happens, bookworm
buildds still build packages in a split-/usr environment (because that
way round has been observed to cause fewer bugs than building in a
merged-/usr environment and installing in a split-/usr environment).
For trixie and newer, the strategy Helmut proposes involves gradually
changing the canonical path of all "/usr-like" files inside packages'
data.tar.*, so that by the time we release trixie it is below /usr in
all cases (for example /usr/bin/bash), which will result in the package
only working as intended if the aliasing symlinks are in place.
I think the question that Ted needs an answer to, for backportable
packaging, is not actually whether the distro version has split-/usr
as a supported configuration or not, but more like: whether it is safe
or unsafe to make all /usr-like paths in data.tar.* be below /usr on
this distro version. In bookworm or older, that is not safe; in trixie,
our goal is that it becomes safe, and indeed recommended. (We are not
there yet!)
Because bookworm-backports is an extension of bookworm and users are
expected to upgrade to bookworm before enabling bookworm-backports,
split-/usr is not considered to be a supported situation there, so it's
reasonable for packages that are outside the critical path for bootstrap
and compilation to assume merged-/usr; but it is (probably) still not
safe for those package versions to canonicalize all their /usr-like
paths into /usr.
> I had *one*
> set of debian files that would successfully build on Debian stable,
> Debian testing, Debian oldstable, Debian oldoldstable [etc.]
This is sometimes a nice thing to be able to do, and we shouldn't break
it for no reason, but it's easy for it to over-constrain the solution
space to an extent that makes distro-wide changes harder or impossible.
Intentionally keeping packaging files (especially d/rules) compatible
with older distro versions comes with a risk of ossifying packaging
and holding back adoption of desirable changes. For instance, I think
we can see echoes of this in the way multiarch library paths have been
best-practice in Debian for at least a decade, but unstable *still*
has libraries in /usr/lib. (Perhaps it's time for some mass-bug filing
or a Lintian check...)
The main things that Debian delivers are the current stable release and
the next stable release, and I think maximizing the quality of those
should be our priority.
smcv
Reply to: