Re: readutmp: load libsystemd with dlopen instead of linking

On 2026-07-20 15:24, Luca Boccassi wrote:

> The issue with that is it's not a static choice, some distros like
> Debian support dynamically switching at runtime an existing
> installation between systemd and anything else.

I don't think we designed Gnulib or coreutils with that possibility in 
mind. Not surprisingly.

Please correct me if I'm wrong in the following analysis.

I assume that by "dynamically" you mean "the sysadmin can switch the 
regime, effectively at reboot time, but cannot switch the regime again 
until the next reboot", not "anybody can switch whenever they like". I 
also assume that regardless of regime, old logins are logged to 
/var/log/wtmp.db in a consistent format, so that programs like 'last' 
work even for old logins done under a different regime. So under this 
approach, programs like Coreutils 'who' have two problems:

1. Figuring out who's logged in right now, since the systemd and 
non-systemd camps disagree about how to make this info available. 
Currently Gnulib readutmp supports only the systemd regime on Debian.

2. Accessing /var/log/wtmp.db via libwtmpdb, a library I never heard 
about until looking into this just now, and something that Gnulib 
readutmp I suppose should link to, if its callers want historical data. 
Gnulib readutmp doesn't do that now, which means coreutils 'who' doesn't 
work to access old data on Debian, regardless of whether the sysadmin 
has chosen systemd.

 From my point of view both of these issues are more serious than the 
relatively minor packaging issue. Is there a good way to address the two 
issues? Or have I misdiagnosed this?


> But aside from that, how can something that is required be optional?

Obviously Debian can't decide that a dependency is both required and 
optional. It must decide one way or another (or it can decide that the 
dependency is entirely unnecessary). But that's Debian's job, not 
coreutils's.


> Saying it's required but it can be
> disabled is contradictory.

Absolutely! But the idea was that the decision was up to the distro 
maintainers. If Debian configures coreutils with --enable-systemd it has 
decided to making libsystemd a dependency for Debian coreutils; 
otherwise, not. Whether the depenendency is required or recommended or 
suggested is up to Debian.

As I understand things, Bruno suggested that Coreutils do nothing about 
this issue, and simply document it. Although that's of course the 
least-work option for coreutils maintainers, I'm thinking that maybe it 
would be better if coreutils uses something along the lines of the 
sd-dlopen module being drafted, so that Debian can more easily make the 
dependency recommended (or suggested) according to Debian's rules.

The proposed changes to Gnulib's selinux and readutmp are more 
problematic. Some Coreutils programs (e.g., chcon) should stay the way 
they are, because they almost always need libselinux. Other programs 
(e.g., mkdir) would benefit from the proposed changes, as they rarely 
need libselinux. The preference there is per-app, not per-package, as 
Coreutils has both kinds of apps. But the proposed changes force all the 
apps into the mkdir-like camp, which is overkill.