On 2026-07-30 12:18, Luca Boccassi wrote:
"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.
It's not that simple. For most coreutils utilities that use libselinux, yes, the library is optional and "suggested" is fine. However, chcon and runcon need libselinux or they always fail, which means they are not doing their job without libselinux, and libselinux is not optional for them. (Similarly for libpcre2, which libselinux requires.)
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.
At least for coreutils, where the binaries are pretty small and don't depend on much, that end result is unlikely. coreutils originally arose by combining several packages. It is plausible that we overdid this, and that some of its binaries should be moved out into separate packages. Not the same packages as decades ago, but packages suitable for today. One possible breakdown would be: Move these to selinux-utils (or create a new package for them): chcon, runcon (libselinux, libpcre2 required) New package cksum-utils: b2sum, cksum, md5sum, sha1sum, sha224sum, sha256sum, sha384sum, sha512sum (libcrypto, libz required for all but b2sum) New package who-utils: pinky, users, who (libsystemd, libm required) coreutils - everything else currently in coreutils Each of these broken-out packages addresses a clearly separable set of utilities, so this breakdown is not simply because of runtime dependencies: it's something that users could well appreciate even if there were not runtime issues. Also, this approach would not separate out coreutils programs needing libacl, libattr, libcap, libgmp asause those programs are so core that nobody will want to omit them anyway (e.g., ls), because the programs don't always fall into such neat packages like the above, and because (I assume) those libraries are installed everywhere anyway. As the previous paragraph suggests, this sort of thing is a judgment call. The point I'm trying to make is that we need not go to one package per binary: we can instead have packages with reasonable scope, something coreutils arguably is currently not.
