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]
> 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].
> 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.
> As per request, I've removed the silent fallback to the old method if
> the library is not found.
Thanks.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2026-07/msg00017.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2026-07/msg00033.html
[3] https://lists.gnu.org/archive/html/bug-gnulib/2026-07/msg00045.html
