Package: tech-ctte

Hello committee members,

I fear I am faced with another road block in the /usr-move transition
and seek assistance with a packaging authority question #1079329. The fundamental question is who has authority to touch the aliasing symbolic
links such as /lib64. Until bookworm, there was no clear authority as
multiple packages (including but not limited to base-files, debootstrap,
glibc, systemd, usrmerge) touched them. As part of the /usr-move
transition, I moved authority of these links to base-files exclusively
as it now installs them via its data.tar. At least I thought so. systemd maintainer Luca Boccassi disagrees and sees systemd having authority in managing them. It has been demonstrated that this may cause an
installation failure of base-files in practical ways. In particular,
systemd assigns a different link target than base-files does. The base-files.preinst has been augmented to catch this situation and abort
early to avoid a subsequent unpack error. Luca Boccassi argues that base-files.preinst should fix up the link left behind by systemd. I
agree with that on the condition that we first fix the cause for the
wrong link (systemd), but Luca disagrees with changing systemd in this
regard. Doing so would deviate from upstream behaviour. As systemd
manages non-Debian containers, the management of /lib64 is necessary and removing the link may break such container workloads (though a systemd
upstream MR to validate this claim turned up no actual breakage in
systemd's CI pipeline). As a result of this impasse, systemd continues
to set up a /lib64 that is incompatible with base-files and
base-files.preinst continues to fail installation.

I ask the technical committee to overrule the systemd maintainers and authorizes me to NMU the proposed change[1] stopping systemd from
setting up an incompatible /lib64 symlink.

Let me stress that allowing /lib64 to point to different unpredictable
targets violates fundamental assumptions of the /usr-merge whose stated
goal was to treat /lib64 and /usr/lib64 interchangeably. Revoking this assumption revokes the basis for the /usr-move transition that the CTTE authorized me to carry out in repealing the moratorium.

Technically speaking, there is one more feasible workaround. If the
base-files package were to install an empty /usr/lib64 directory and the
/lib64 -> /usr/lib64 symbolic link in its data.tar for all
architectures, then the logic embodied in systemd now would never
trigger the offending code path for Debian installations and the problem
would likewise go away. I argue that this change has a significant risk
of confusing users of non-amd64 systems and therefore rejected it. You
may also overrule me and request that either base-files allows the link
to be unpredictable or unconditionally ships it for all architectures.

Both ways require a 3:1 majority vote via constitution 6.1.4.

Helmut

[1] https://github.com/systemd/systemd/pull/34804

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 03 Jan 2025 at 10:02:43 +0100, Helmut Grohne wrote:

Hello committee members,

(I am no longer a TC member, but I'm still on the mailing list)

In particular,
systemd assigns a different link target [for /lib64] than base-files does

If I was a TC member, the first question I would be asking is: what target?

I believe base-files creates /lib64 -> usr/lib64. Correct?

What conflicting symlink does systemd create under at least some
circumstances? Is it /lib64 -> usr/lib?

What architectures are affected by this? My reading of #1079329
is that it potentially affects any architecture that *does not*
have its canonical/interoperable ld.so(8) path in /lib64, so in
particular arm64 is usually affected (because arm64's canonical ld.so
is /lib/ld-linux-aarch64.so.1, so there is no reason why a minimal
arm64 system necessarily needs to contain /usr/lib64) but amd64 is not
(because amd64's canonical ld.so is /lib64/ld-linux-x86-64.so.2,
so every working usr-merged amd64 system must already contain /usr/lib64/ld-linux-x86-64.so.2).

If https://wiki.debian.org/ArchitectureSpecificsMemo is accurate, the
loong64, mips64el, ppc64* and sparc64 architectures are in the same
equivalence class as amd64 (/lib64 exists as ABI), and all other known
official and -ports architectures are in the same equivalence class
as arm64.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Simon,

On Fri, Jan 03, 2025 at 10:43:21AM +0000, Simon McVittie wrote:

(I am no longer a TC member, but I'm still on the mailing list)

I appreciate your feedback and asking questions that move discussions
forward.

If I was a TC member, the first question I would be asking is: what target?

I believe base-files creates /lib64 -> usr/lib64. Correct?

What conflicting symlink does systemd create under at least some circumstances? Is it /lib64 -> usr/lib?

I confirm all of the above.

What architectures are affected by this? My reading of #1079329
is that it potentially affects any architecture that *does not*
have its canonical/interoperable ld.so(8) path in /lib64, so in
particular arm64 is usually affected (because arm64's canonical ld.so
is /lib/ld-linux-aarch64.so.1, so there is no reason why a minimal
arm64 system necessarily needs to contain /usr/lib64) but amd64 is not (because amd64's canonical ld.so is /lib64/ld-linux-x86-64.so.2,
so every working usr-merged amd64 system must already contain /usr/lib64/ld-linux-x86-64.so.2).

If https://wiki.debian.org/ArchitectureSpecificsMemo is accurate, the loong64, mips64el, ppc64* and sparc64 architectures are in the same equivalence class as amd64 (/lib64 exists as ABI), and all other known official and -ports architectures are in the same equivalence class
as arm64.

I confirm your understanding. The equivalence class of amd64 is entirely unaffected by this, because it always contains /usr/lib64 and in that
case, the link that systemd creates is compatible with base-files.

To see how this setup may pose practical problems, consider using an
ARM64 laptop. This system usually lacks /usr/lib64 and systemd creates
/lib64 -> /usr/lib. Now you install box64 or qemu-user and libc6:amd64
to run some amd64 application. This will not update /lib64 as it already exists. Executing the binary now fails, because
/lib64/ld-linux-x86-64.so.2 does not exist. We installed it to
/usr/lib64 trusting that the symlink would make it visible in the
required location.

This very much is a Debian-specific problem, because Debian is the root
of the only Linux distribution hierarchy that does multiarch and allows
pretty much arbitrary combinations of architectures. Everywhere else
you'd rather set up a container where there would be a separate /lib64
that systemd would setup in a different way. The systemd assumption here
is that /lib64 can be architecture-dependent, but that assumption is
rendered invalid by multiarch.

I think there is one more way out here. We may choose to install
/usr/lib64 as a symlink to lib (e.g. in base-files' data.tar) and then
move ld-linux-x86-64.so.2 to /usr/lib in libc6:amd64. At that point, we
no longer care whether /lib64 points to /usr/lib64 or /usr/lib (both
work equally well). This actually is rather close to what Arch Linux
does. Going this route requires killing multilib as the multilib
libraries (e.g. libc6-amd64:i386) would then collide with system
libraries. I don't think I'd miss multilib as our cross toolchains have
matured significantly, but I expect others to disagree and you're back
to overriding a different developer.

As far as I understand it, we may pick any three:
* Allow systemd to manage /lib64 as it does.
* /usr-move
* Multiarch
* Multilib

No matter how you choose here, one of these will be broken.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)