Re: [PATCH] readutmp: load libsystemd with dlopen instead of linking

Paul Eggert <[email protected]> Thu, 16 Jul 2026 11:47:53 -0700
Newsgroups gmane.comp.lib.gnulib.bugs
Organization UCLA Computer Science Department
Message-ID <[email protected]>
On 2026-07-16 11:14, Luca Boccassi wrote:
>   We are not going to add random per-package scripts and hacks.

OK, your call.

> After umpteen emails, you still have failed to raise a single issue
> with the actual patch

Sure we have: it complicates coreutils and adds maintenance burden. From 
the upstream point of view, why add random hacks to make it easier for 
distros to purposely break some apps? Admittedly this is a judgment call 
- just as the rejection of the optional-libsystemd script is a judgment 
call - but it's seems reasonable for upstream to say "Umm, no" here.


> why isn't the
> same issue already affecting openssl? I don't see any
> "optional-openssl" script for it

For that situation, the extra complexity is worth it, as it speeds up 
'sort' in the usual case and it makes 'sort' a bit more reliable.

For the readutmp situation, the extra complexity does not appear to be 
worth it.

Another option is that Debian could maintain a downstream patch along 
the lines you're proposing. (A downstream patch along the lines I'm 
proposing would also work, although you've rejected that.) Debian 
coreutils already has a patch for something else, so the mechanism for 
downstream patches is already there.

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.