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.
