On Wed, 15 Jul 2026 at 17:09, Bruno Haible <[email protected]> wrote: > > Luca Boccassi wrote: > > > I'm a bit more puzzled. I also don't see why (b) doesn't suffice. > > > Certainly (b) is simpler. And I am dubious about the dlopen business in > > > general; it's not needed for the other libraries coreutils dynamically > > > link to, and why is libsystemd special? > > > > coreutils _already_ uses dlopen (correctly!) to optionally load > > openssl for an optional feature in sort: > > > > https://github.com/coreutils/coreutils/blob/fb631c3e6dd29d89e4c65b8e3969deb1db2bcb98/src/sort.c#L2396 > > But that's a different situation: Use of openssl in coreutils is > there to _enhance_ the coreutils functionality (regarding speed). > > Whereas regarding libsystemd in 'who', 'users', 'pinky' is a different > situation: These three programs are useless / broken if they can't > get the info from libsystemd. [1][2]
It's really the same situation. There is one package that ships all the binaries together, so libsystemd enhances the coreutils package with optional functionality that is seldomly needed. It's not useful to think in terms of individual binaries, as no major distribution of relevance separates them anyway, so for all intents and purposes it's a single unit. > > As already mentioned, libraries that are linked to binaries in all > > distributions are _hard_ dependencies, as the binary fails to load > > entirely if they are missing. It just crashes on startup, and you > > can't even run --help or so, which is very much not what we want. > > Regarding the "which is very much not what we want" part: > I don't know from which world you are coming. In the world I am coming > from, it is perfectly OK for a program to quit with an error message > if an essential dependency is missing. And the default diagnostic is > even quite decent [3]. In the world I am coming from, which is the one of the most relevant linux distros, this situation can never happen by construction, as every library mentioned in the dynamic symbols table of a binary is automatically made into a mandatory dependency of the package that ships it. This is not something that will ever change. > > That's why the process of adding dependencies for linked libraries is > > entirely automated, and it is not something that is handled manually, > > and _we do not want_ to handle it manually. Which is why your proposal > > of "just not installing the library" is not an option. If it's linked, > > then it's a hard dependency of the coreutils package, and thus it > > always gets installed and cannot be skipped. The dependencies and the > > dependency tree is the same for all use cases and it's part of the > > package metadata. There's no functionality to do so, and there will > > never be, as things would break left and right. > > Your argument is, AFAIU: > (1) There is only one 'coreutils' package, and it must be usable for > all situations. > (2) Distros should not need to split the 'coreutils' package. > (3) Creation of a chroot environment uses the package manager. > (4) (3) is not tailorable: There is no way to modify the chroot > environment after the package manager has run. > > (3) is indeed correct: The typical way to create a chroot environment is > a shell command: > > * Debian 13: > sudo debootstrap stable CHROOTDIR http://deb.debian.org/debian > * Ubuntu 26.04: > sudo debootstrap resolute CHROOTDIR http://archive.ubuntu.com/ubuntu > * Fedora 44: > sudo dnf --installroot=CHROOTDIR --releasever=44 --use-host-config install > @core > * openSUSE: > sudo zypper --root CHROOTDIR install --no-recommends > patterns-base-minimal_base > > But this is just one shell command. Every system that can execute > a shell command can also execute additional shell commands, such as > rm -f CHROOTDIR/usr/bin/who > rm -f CHROOTDIR/usr/bin/users > rm -f CHROOTDIR/usr/bin/pinky > rm -f CHROOTDIR/usr/lib/x86_64-linux-gnu/libsystemd.so.0* > rm -f CHROOTDIR/usr/lib64/libsystemd.so.0* > > There are other programs which are not needed in a minimal chroot environment, > which could be removed alike: > rm -f CHROOTDIR/usr/bin/gencat [present in Fedora44] > > So, I claim that the assumption (4) is invalid, and that it is perfectly OK, > when creating a minimal chroot environment, to remove programs through > additional shell commands. Nah, it is not ok at all. Nobody wants to be bothered with adding horrid manual hacks for every corner case of every single one out of 60k different packages to every single image-building tool (of which there are approximately a different one for every linux dev in the world, or so). Often it's not even possible, as the image is produced immutable from the get-go (erofs/squashfs). This is just not how things work in the real world, sorry. That is why myself and many others are busy making this work properly, without manual hacks such as those you have just described, and making dependencies in core packages that are only needed for optional functionality, optional at runtime. Every single dependency of systemd is now dlopen'ed since the most recent release, and in util-linux's next release libselinux will be dlopened too: https://github.com/util-linux/util-linux/pull/4480 More work in other packages is also ongoing.
