Luca Boccassi <[email protected]> writes: > On Tue, 21 Jul 2026 at 06:09, Sam James <[email protected]> wrote: >> >> Paul Eggert <[email protected]> writes: >> > That being said, to cater to a user population that thinks coreutils >> > works "just fine" even if 'who' always fails, how about if we instead >> > look into another idea that I think was briefly mentioned earlier: >> > namely, packagers run a shell command "optional-libsystemd who pinky >> > users", where optional-libsystemd is something like the attached >> > script. >> > >> > The optional-libsystemd script could be generalized to do something >> > similar for other dynamic libraries that have this issue. (As an >> > aside, it is annoying that objcopy makes this sort of thing such a >> > pain but perhaps objcopy could be improved to make it easier.) >> > >> > Although the script puts a bit of the burden on the packagers, the >> > feature's burden must go *somewhere*, and since packagers want the >> > feature they are more likely to maintain it well. >> >> Not all packagers want this. I consider this undesirable where we know >> we will be deployed on a system that, say, uses SELinux. systemd >> currently as of bda98358d29336b285450c6d3e2c9d6a634efddd will do: >> >> int dlopen_libselinux(int log_level) { >> #if HAVE_SELINUX >> static void *libselinux_dl = NULL; >> >> LIBSELINUX_NOTE(suggested); >> >> i.e. if you build systemd with libselinux support, it is merely >> 'suggested', yet if you rely on SELinux support, that's not the case at >> all. >> >> 'suggested' is subjective and depends on if you know where it is going >> to be deployed. > > Whether a system runs selinux or not, is not a determination that > coreutils can do. It is not possible to use selinux without a policy > and other selinux-specific utilities, and those packages already have > (correctly) a hard dependency on libselinux, and will pull it in.
We have users who are not be using the reference policy (or a packaged policy at all). But if we're going to discuss transitive dependencies, you don't need the userland utilities if you don't want them, and one indeed might not have them in a minimal environment. But anyway.. How do you detect that it's really needed in that case (or suppose some analogous case where no 'policy-alike' exists)? The note is there but it says 'suggested', but it's not really suggested for that use case. If we want to generalise this in the package manager, we'll need to be able to say "suggested deps aren't that important" (which is what the spec indicates: https://uapi-group.org/specifications/specs/elf_dlopen_metadata/#priority-definition) so as not to spam with tonnes of QA warnings for things when they're not really needed, yet suggested isn't accurate for this case. If one really wants to elide the libselinux dep, just don't build with support for it? > Hence the fact that coreutils or systemd do not have a hard dependency > on the libselinux package does not affect selinux users. Coming back to systemd+who, I don't understand why it's not an option to just omit installing the 'who' package (or whatever contains it, split it as appropriate) in a container environment instead. Presumably you already have to do something as a user to stop it installing libsystemd as a recommended (in Debian parlance, not the spec parlance) dependency anyway? In such a case, why is it different to just remove 'who', or tell people to run something else to install it, as they're already having to do something to avoid libsystemd? If, alternatively, it is not pulled in by default, then it seems like recommended or suggested (in the spec parlance) doesn't help avoid broken functionality and it's not worth using. sam
signature.asc
Description: PGP signature
