Simon Josefsson wrote:
> I suspect Luca's point of view could be that is EASIER [for him] if this
> complexity is moved into each application, rather than have him/everyone
> do the extra commands of (4). Both approaches are _possible_, but which
> approach to prefer probably depends on if you are maintaining the C code
> or want to create minimized container environments. This is a bit
> subjective IMHO. Complexity is a problem in both places.
Thanks for bringing up these higher-level thoughts.
At this higher level, I have two problems with Luca's request:
* Distros should package the code that developers produce.
It's not the developers who should obey the distros.
The first reason is that the distros and their wishes change way too fast.
Over the last 30 years, distros have been migrating from installation
from piles of floppy disks to live installers on CDs and USB sticks.
Distros have been introducing separate packages for the documentation.
Distros have been splitting source packages into many pieces [1].
Distros have been using specific compiler options, other than "-O2 -g",
for security.
Distros have been experimenting with the option "-flto", which works
for some packages but not for others [3].
Distros have been adapting their file system standards continually
(e.g. /bin → /usr/bin, /sbin → /usr/sbin).
Whereas in the same 30 years, the source code of any C program could
remain unchanged (if it wasn't for updated C standards, for
internationalization, and the like).
The GNU coding standards already make the work of the distros easy,
through the 'configure' command-line convention and the 'make install'
target, that work essentially the same across all packages.
Of course, when distros have a certain desire and the developers can
easily accommodate that (e.g. a variable to designate the utmp/utmpx
file), that's fine.
The second reason is that different distros have different desires.
GNU clisp went ahead to support different distros better, and now
has a command-line option --fsstnd=debian / --fsstnd=redhat /
--fsstnd=suse. This is wasted effort; it should have been the
distros which tailor the installation through their .spec files.
* Luca says: the dependency coreutils → libsystemd should be changed
from Requires to Recommends.
I and Paul say: no, it's an essential dependency, not an optional one.
Luca says: I don't care, I want it anyway.
This kind of conversation is not going to be successful.
Instead, if distros really want to support building minimal environments
with coreutils but without libsystemd, they should tailor the binary
packages. I can very well see it being split into two separate binary
packages (at the distro level, similar to [1]):
- 'who', 'users', 'pinky', and maybe a few others ('groups') that
are not meaningful in containers / chroot environments go in a separate
package,
- the other coreutils programs should remain in the 'coreutils'
binary package.
It will be useful if the coreutils developers suggest this to the
distros, e.g. through a file 'PACKAGING' like other GNU packages do [2].
Bruno
[1] https://packages.debian.org/trixie/source/inetutils
[2] https://gitweb.git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=PACKAGING
[3] https://lists.gnu.org/archive/html/bug-gettext/2026-05/msg00011.html
