Hello,

In Bug #1091995, the Technical Committe was asked to rule on an issue
that could, under certain circumstances, result in failure of the
base-files package to install or upgrade correctly. Under these
circumstances, systemd will create a symlink from /lib64 to /usr/lib,
which does not match the symlink contained within base-files. base-files
will detect this case in preinst and generate an error, but if it did
not do this then dpkg would instead fail with a less verbose message.

Policy does not currently define ownership of the usrmerge filesystem
aliases, but since trixie base-files has effectively been responsible
for ensuring that these aliases are configured appropriately. This is
therefore a technical disagreement rather than a policy violation.

The Technical Committee affirms that base-files should own all
top-level filesystem aliases, and packages that conflict with this must
be patched in Debian to avoid creating any aliases that conflict with base-files. In doing so, the Technical Committee overrides the systemd maintainers.

For complete details of the discussion, please see https://bugs.debian.org/1091995

Regards,

Matthew (for the Technical Committee)

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

* Helmut Grohne <helmut@subdivi.de> [250307 07:05]:

Hi Sean,

On Thu, Mar 06, 2025 at 05:39:06PM +0800, Sean Whitton wrote:

Just to note that the most recent release of Policy sort-of defines ownership of this, though it is not as explicit as the TC decision:

Packages must not install files to paths whose first component is a
name directly under the file system root and which is a symbolic
link to a directory of the same name under "/usr". ... The
base-files package is an exception, for it installs aliasing
symbolic links from "/bin" to "/usr/bin", "/lib" to "/usr/lib", et
cetera.

Thanks for highlighting the additional context. A significant angle here
is what it means to "install". systemd does not presently install those symlinks at package installation time, so it may be argued that it does
in fact not violate the updated policy in this regard.

Are you saying that systemd creates the symlinks at runtime when it
finds them missing, rather that when the systemd package is installed?
To me, this is a clear violation of the policy quoted above. "...must
not install..." says nothing about when the installation happens.
Installing a symlink is distinct from installing a package. The act of creating the symlink is exactly "installing" it, whether it happens at
package installation or later.

...Marvin

Even after the requested change has been effected, systemd will continue
to create the aliasing symlinks when missing. This kinda is intended as
a mechanism supporting hermetic-/usr. Longer term, it shall become
possible to install Debian in such a way that the entire installation
lives below /usr (though it will not be possible to upgrade such an installation due to the lack of /var/lib/dpkg in the initial
implementation). Then systemd may assemble a system from the
Discoverable Partitions Specification (https://uapi-group.org/specifications/specs/discoverable_partitions_specification/).
It may locate a /usr filesystem and an empty root partition and
initially populate the latter. That population step includes creating aliasing symlinks such as /bin -> usr/bin. You may argue that this constitutes an "installation" and thus violates policy.

Can you clarify how you understand policy here?

I read it as systemd is not performing an installation here and
therefore does not violate the present policy. If your reading is
different, we should likely clarify policy on this aspect.

Helmut

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

On Fri, Mar 07, 2025 at 08:14:00AM -0500, Marvin Renich wrote:

Are you saying that systemd creates the symlinks at runtime when it
finds them missing, rather that when the systemd package is installed?
To me, this is a clear violation of the policy quoted above. "...must
not install..." says nothing about when the installation happens.
Installing a symlink is distinct from installing a package. The act of creating the symlink is exactly "installing" it, whether it happens at package installation or later.

You are reading it correctly. systemd is creating /bin, /lib, /sbin and
in some situations also /lib64 when it finds them missing at runtime
(e.g. during system boot from the initramfs before pivot_root). In a
pretty normal installation this code path is not takes. For one thing,
those links tend to exist and existence prevents systemd from touching
them. For another, our default initramfs does not involve systemd.

If we consider this behavior a violation of the present policy. I
believe that we should change it. Having systemd create those links when missing is crucial for implementing hermetic-/usr and I see little
reason for our policy to forbid that use case.

What was decided by the CTTE here is that systemd must not create links
that are *incompatible* with the ones base-files creates. In particular, systemd must not create /lib64 -> usr/lib as a result of the CTTE
decision.

Helmut

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