On Thu, 16 Jul 2026 at 15:34, Bruno Haible <[email protected]> wrote: > > 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]
It is clearly not mandatory functionality, as the package works just fine without it, minus some optional features that are seldomly needed. Besides, you can always upgrade the dependency strength in the packages you maintain, if you feel it necessary. Loading at runtime via dlopen doesn't forbid that, it simply makes it possible to downgrade it, which is not possible otherwise.
