Hi Luca,
> > Whereas regarding libsystemd in 'who', 'users', 'pinky' is a different
> > situation: These three programs are useless / broken if they can't
> > get the info from libsystemd. [1][2]
>
> It's really the same situation. There is one package that ships all
> the binaries together, so libsystemd enhances the coreutils package
> with optional functionality that is seldomly needed.
> ...
> In the world I am coming from, which is the one of the most relevant
> linux distros, ...
> ...
> That is why myself and many
> others are busy making this work properly, without manual hacks such
> as those you have just described, and making dependencies in core
> packages that are only needed for optional functionality, optional at
> runtime.
Since you are arguing with regard to distros and package management,
let me take a closer look at that.
There are three kinds of package dependencies that are relevant here:
* "Requires" (called "Requires" in .rpm, "Depends" in .deb)
is a mandatory dependency.
* "Recommends".
* "Suggests".
"A requires B" implies that when A gets installed, B must get installed
as well.
"A recommends B" implies that when A gets installed, B gets installed
by default as well. But B will not be installed when the package manager
is instructed to ignore "Recommends" dependencies:
* Debian/Ubuntu:
- apt --no-install-recommends
- debootstrap [already by default, does not need an option]
* Fedora:
- dnf --setopt=install_weak_deps=False
* openSUSE:
- zypper --no-recommends
"A suggests B" does not imply that B gets installed. Typically B is
only shown as suggestion to the user. (E.g. glibc → glibc-doc)
Currently the dependency coreutils → libsystemd is a "Requires".
What you are pushing for is that this dependency becomes a "Recommends".
(I infer this from your "minimal environments" argument and from you
insisting on using the distro's package management tool without tailoring.)
Both Paul and I are saying: This is not appropriate, because it's mandatory
functionality of the coreutils package, not merely an enhancement.[1][2]
To which you are replying that you don't accept our argument.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2026-07/msg00017.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2026-07/msg00033.html
