On Wed, 22 Jul 2026 at 08:02, Paul Eggert <[email protected]> wrote: > > 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?
I believe you are correct, and again the key thing here is that the exact same packages are involved in both cases, there are not separate builds of coreutils for each of them. So making libsystemd runtime-optional, with a fallback in case it is missing as I had it in one of the revisions, should help with this use case as well. > > 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. But that's my point: it's not even the debian packager's role to do that, it's who puts together the image that decides if something like selinux or libsystemd is required or not. > > 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. As above, if I build an image with a selinux policy and selinux=1 enforcing=1 on the kernel cmdline, then libselinux is required. If I build an image without a policy and with selinux=0 on the cmdline, then selinux is not required. In both cases, exactly the same packages are involved. So it's not the debian packager that can decide the dependency level, it's those who consume the packages. By having the strict dependency, only the first case can get maximum utility from the setup. By having a soft dependency, both can, by tailoring the image exactly to their needs.
