On Wed, 22 Jul 2026 at 03:06, Sam James <[email protected]> wrote: > > 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.
"suggested" is the appropriate level here, as it's not the main purpose of the coreutils package, or any other of the 382 packages that use the libselinux library currently in debian stable, to ensure that system-wide support for selinux is in order, and they all perform their job with or without it. We have packages in the distribution specifically for that role, and image builders that do their own thing with policy etc. have the means to do that as well. The key thing here is, you can always make a soft dependency stricter, but not the other way around, the tools and infrastructure do to permit it. So the maximum utility is achieved in this case by marking at the least strict level, and those who need it can pull it in via the package list, and those who don't want it disable soft-dependency resolution, and that way everyone can get what they want, how they want it. > If one really wants to elide the libselinux dep, just don't build with > support for it? There are different roles involved here: the package builders and the image builders. Those are not the same. There is a single set of packages for each component, you cannot have with-selinux and without-selinux versions, so what generalist distributions do is provide as many features as possible, to maximize utility. Image builders then pick and choose from that set. But they do not rebuild packages, as that would entail being a different distribution altogether. And that's why making such dependencies runtime-optional is useful: so that generalist distributions can build the base packages with all the optional features built-in, but then images can be assembled according to the specific needs, and pull those dependencies in or not, without having to fork the entire distro, which is a daunting task and beyond reach of most people. This is not theoretical btw, it happens daily, I myself build images in several systems, and I'm sure many others do as well. > > 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? There's no such separate package. The problem with that line of reasoning is that the only end result it leads to is one package per binary. And even that might not even be enough. It doesn't work out, as the fixed per-package overhead from splitting into ~100 sub-packages would eat up most of the gains. > 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
