Re: readutmp: load libsystemd with dlopen instead of linking

Simon Josefsson via Gnulib discussion list <[email protected]> Mon, 20 Jul 2026 21:19:50 +0200
Newsgroups	gmane.comp.lib.gnulib.bugs
Message-ID	<[email protected]>
Luca Boccassi <[email protected]> writes:

> On Mon, 20 Jul 2026 at 19:41, Simon Josefsson <[email protected]> wrote:
>>
>> 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?
>
> Up to the point people are willing to do the work, as with everything else
>
>> Do you think it is reasonable to replace all shared libraries usages
>> with opt-in use of dlopen()?
>
> In some cases, yes. Every single dependency (bar glibc) in systemd is
> as of now a runtime-optional dlopen library. It works really nicely,
> and allows a single build to be fully-featured while still maintaining
> arbitrary composability.

Would you argue the same for LibreOffice or some similar package?

I think your argument only works for a quite limited number of packages,
and I'm not even sure the balance is right even for a low-level package
like coreutils.

I do believe, instead, that we should consider moving multi-user tools
like 'who users pinky' out of the "common" set of core Unix tools that
always needs to be installed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142500

>> >> 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.
>
> It's really not, every time functionality is expanded or moved,
> binaries need to move too, and as we know dpkg is atrociously bad at
> handling that.

It requires a bit of work (writing proper Depends/Recommends/Breaks and
doing testing), but definitely much less than you are asking for here,
right?  I've moved binaries between packages a couple of times, and
while it may not be a pleasant task, it works.

> If every binary gains such functionality, you are back to square
> one. It's really not a good way to organize things, as it's
> fundamentally disjoint: the way features are implemented, and the way
> subpackages are split out, are completely orthogonal and independent
> and do not move in unison.

Often they are related though.  It seems the tools that need libsystemd
in coreutils are multiuser tools, and those do not feel particulary
relevant in a container.  They could go into a separate package.

Can we confirm that only 'who', 'users', and 'pinky' REQUIRE the use of
libsystemd for essential functionality?

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