bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

[Assaf Gordon]

tags 33787 wontfix
close 33787
stop

Hello,

On 12/17/18 11:12 PM, L A Walsh wrote:
> I find that /etc/xattr.conf is being used to regulate behavior in gnu
> tools.

It's worth noting that "/etc/xattr.conf" comes from a shared-library
(libattr.so) that is optionally used by cp(1).
It is not part of GNU coreutils per-se, and coreutils developers have
no influence over it.

Similarly, if other shared-libraries decide to introduce their own
global configuration files, it will be picked-up by coreutils' cp
(e.g. libacl, libcap or libsmack).


On 2018-12-20 3:40 p.m., L A Walsh wrote:
> On more than one coreutils-including system, I see coreutil programs 
> replaced with alternate versions like from BSD
> because the bsd version was more user friendly.

There are several cases where GNU coreutils' programs are
not the default, and instead other implementation are used
(e.g. "busybox" in Alpine Linux).

I'm less familiar with cases where the BSD implementation is used
to replace coreutils in GNU/Linux systems, but that's certainly
possible.

However, I doubt that is because these other implementation are
more "user friendly". Typically other implementation are used
due to less restrictive license (e.g. BSD vs GPLv3),
or due to perceived "bloat" (i.e. desiring *less* features and
smaller binaries than what GNU coreutils offer).

> Coreutils should service the owner of the system.
> They should not be like a virus or malware that can change
> behavior at the behest of the util-maintainer against what users want.  
> This has been what is happening.

I humbly think calling it a "virus or malware" is an exaggeration.

All GNU coreutils program do exactly as you tell them by supplying
command-line arguments. Your request is to add a global configuration
file that would save some typing.
Even without such a config file, it's hardly going "against what users
want".

> Those things said, coreutils apparently is already using xattr.conf
> and my proposal is to fold that into a gnu.conf where other
> utils can store config ops, or go ahead and provide gnu.conf even if 
> xattr.conf doesn't want to fold in to allow more flexibiltiy

As mentioned above, "xattr.conf" is not managed or created or
used by coreutils programs per-se (i.e. there is no where in GNU
coreutils' source code a place where xattr.conf is read).

It will not be merged or folded into a hypothetical "gnu.conf"
because these files are targeting different projects (coreutils vs
libattr).

This is just like "/etc/passwd" won't be merged with "/etc/pam.conf"
despite both of them being related to user management - they are from
different projects.

---
The common and recommended way to add default command-line arguments
is to use aliases (e.g. "alias rm='rm -i'").

If used in $HOME/.profile - it will affect your interactive use.
If used in /etc/profile (or similar) - it will affect all users in your
system.

That method already works in almost every Unix system - without adding
additional code and complexities of a global configuration file.
---


> On 12/20/2018 1:59 PM, Paul Eggert wrote:
> > Coreutils should not behave differently on different hosts merely 
> > because the coreutils installer on one platform prefers behavior A 
> > whereas the installer on another platform prefers behavior B.

Given the above, I'm closing this as "wontfix".
Discussion can continue by replying to this thread.

regards,
- assaf