Re: readutmp: load libsystemd with dlopen instead of linking

Simon Josefsson via Gnulib discussion list <[email protected]> Mon, 20 Jul 2026 20:42:53 +0200

Newsgroups	gmane.comp.lib.gnulib.bugs
Message-ID	<[email protected]>

Luca Boccassi <[email protected]> writes:

>> For the readutmp situation, the extra complexity does not appear to be
>> worth it.
>
> Why is it not worth it? They are different use cases, worth something
> different to different people. One is not better or worse or different
> or more worth or less worth than the other. It's exactly the same
> code, to achieve the exact same goal: make a dependency
> runtime-optional. Incidentally, if it wasn't already a dlopen dep,
> this patch would have made it into one as well, for the same reason.

Where should the line be drawn?  Do you think it is reasonable to
replace all shared libraries usages with opt-in use of dlopen()?

>> Yet another option is that we could split GNU 'coreutils' into two
>> packages. Arguably 'who', 'pinky' and 'users' are no longer core
>> utilities, if so many users do not care whether they work.
>
> End result is worse: more complex, more annoying to handle, less
> flexible, less powerful. And doesn't really help anyway: it's the same
> story for libselinux, which affects more binaries.

I don't understand that argument -- packages are split into several
sub-packages all the time, and users are used to this.

With my Debian (non-coreutils maintainer) hat on, this seems like a good
way to resolve this.  You would have:

Package: coreutils
Depends: ... no libsystemd anywhere ...
Recommends: coreutils-systemd

Package: coreutils-systemd
Depends: ... libsystemd ...

Where the 'coreutils' package would only contains the applications that
do not need systemd, and the 'coreutils-systemd' package would contain
the applications (who, pinky, users) that need libsystemd.

What's wrong with this?

Users will barely notice, and you get the opt-in approach to libsystemd
without forcing libsystemd on all of the coreutils packages.

/Simon

signature.asc (application/pgp-signature, 1.2 KB)