Bug#1091995: tech-ctte: clarify authority of aliasing symbolic links
Hi Josh,
On Sat, Jan 04, 2025 at 10:10:26AM +0200, Josh Triplett wrote:
> Helmut Grohne wrote:
> > As far as I understand it, we may pick any three:
> > * Allow systemd to manage /lib64 as it does.
> > * /usr-move
> > * Multiarch
> > * Multilib
>
> By "/usr-move", do you mean the overall /usr migration, or do you mean
> the idea of linking /lib64 to /usr/lib64 unconditionally (e.g. in
> base-files)? The latter seems like a viable solution, and a *useful* one
> for multiarch. If someone is on arm64 (without /lib64), and they want to
> have amd64 libraries installed, *something* needs to be responsible for
> installing a /lib64 symlink to /usr/lib64, and base-files seems like the
> obvious candidate to do so. That would avoid having to have any special
> logic in packages that need /lib64. The only cost would be having an
> "unnecessary" symlink on targets like arm64 (which stops being
> unnecessary as soon as the system installs multiarch packages from a
> target that needs /lib64).
I would say that the answer is more nuanced.
When I say /usr-move, what I mean is emptying directories such as /bin,
/lib and /sbin but also /lib64 and moving all of their files to the
corresponding /usr location as a mechanism to avoid aliasing effects
from surfacing in dpkg. As such, /usr-move is an extension of
/usr-merge, which merely says that /bin, /lib, /sbin and a few more are
symbolic links. (Let's forget about the alternative merge via symlink
farms for now.) The implication of /usr-move is that libc6:amd64
installs /usr/lib64/ld-linux-x86-64.so.2 rather than
/lib64/ld-linux-x86-64.so.2 and expects /lib64 to always exist.
Your suggestion of having these links managed by base-files is already
implemented. In trixie and later, base-files installs /bin, /lib, /sbin
as symlinks via its data.tar. On amd64, it also installs /lib64 that
way, but not on arm64. (Please consider these equivalence classes with
an eye towards Simon's mail.) If you install libc6:amd64 on an arm64
installation, it will unpack /usr/lib64. This unpack happens to activate
a base-files trigger and base-files will subsequently create the /lib64
symlink. I think we already are where you want us to be as you may
practically assume /lib64 to exist whenever any package installs
anything into /usr/lib64.
Unconditionally installing an empty /usr/lib64 (and /lib64) for all
architectures is something that would technically work indeed. Once
/usr/lib64 exists everywhere, the logic in systemd will never create a
/lib64 -> usr/lib symbolic link and the dispute is resolved. I happen to
disagree with this being a good solution, but the CTTE may overrule me
here.
Helmut
Reply to: