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

From: Assaf Gordon <[email-masked]>
Date: Thu, 20 Dec 2018 19:21:45 -0700

Hello,

On 2018-12-20 6:46 p.m., L A Walsh wrote:
> 
> 
> On 12/20/2018 5:21 PM, Assaf Gordon wrote:
> 
>> If you are requesting such features (or others)
>> It's best to start a new thread for each topic.
> ----
> 
> They've already been discussed and ignored because there was no
> way to add the feature for a default behavior other than
> ENV vars or a config, both of which have been rallied against
> to maintain the behavior monopoly with the existing devs.
> 

There are few separate issues above:

1. If any messages have been ignored (that is: not replied to at all) -
that's not OK. It happens, as the maintainers volunteer their time
and sometimes messages fall between the cracks, but we try to minimize
these occurrences.

If you (or any one else) have sent a message that have not been replied
to - please do send a gentle reminder to the list
(perhaps with a link to the original message from the mailing list 
archives).

2. If a topic has been discussed, and the suggestion or request wasn't
accepted - as frustrating as it is, it is the prerogative of coreutils'
maintainers to decide what goes in and what's not.
Several of my own suggestions were rejected, I certainly understand it
is frustrating. Topics can always be revisited if there are new
reasons to suggest a feature. Supplying a working patch is also
a way to make a stronger case.

3. Every feature in the coreutils'  programs, whether existing or
future-suggested, can and must have a command-line parameter option.

Saying "there was no way to add the feature [...] other than ENV vars or
a config" is technically incorrect. If a feature is accepted, it will
have a command-line parameter. There are no features that can only be
set by ENV-vars or a config file.

4. The corollary of #3 is - once a feature has a command-line option,
you can change the default (interactive) behavior with "alias"
or shell functions, and can change the (non-interactive) behavior
with a simple shell-script.

5. New ENV vars are frowned-upon for reasons that have been discussed
several times before (see: 
https://www.gnu.org/software/coreutils/rejected_requests.html).

6. Support of a global gnu-wide configuration file is a feature request
that was not accepted (previously in this thread).

----

Please understand that requests for configuration files and ENV vars
are orthogonal to requests for new features.

regards,
  -assaf