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

Previous Next

Full log

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: L A Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Assaf Gordon <assafgordon <at> gmail.com>, Coreutils <bug-coreutils <at> gnu.org>
Subject: Re: bug#33787: Policy Change: Use of /etc/gnu.conf files to configure
 default system behavior
Date: Thu, 20 Dec 2018 17:42:52 -0800

Features where their non inclusion was unable to be met due to
pre-existing usage and where using or allowing behavior change based
on ENV vars was disallowed due to new gnu policies to minimize usage
of ENV vars.  At the time config files were mentioned as a possible
solution but at the time I was told there would be no more config files.

Now I'm seeing references to /etc/xattr.conf regarding which attributes
should be copied and which not when utils like 'cp' or 'tar' preserve
or restore xattrs.  If you don't allow a config, how will you skip
attributes that shouldn't be copied on a given system vs. those that 
should?

As for random features being added, paul, who was it that added a random
range feature incompatible with what was original suggested and going off
in a different direction.  You created an incompatible feature to the 
one that was originally proposed... so this is to allow a workaround for
for malicious features rushed to build to disallow alternate sets. It's
not about a new random one, but one that you specifically found an
alternate and incompatible algorithm for.  It certainly is no more of
a random feature than the collection of new features that has gone
into random coreutils programs in the past year or two -- many of which,
like with 'ls' were strongly complained about -- and ignored.

Those people who don't like the new, unwelcomed 'features' forced 
upon them would have a choice.

Similarly with 'find' -- supposing to use the user provided prefix
prepended on targets, when this doesn't:

"find -type f" doesn't emit plain filenames, but "./" appended to each.

But if you want "./" appended, you already have
"find . -type f".  There are several little nitnats that came down to 
the dev's choice overriding things users suggested or wanted.
This would allow users to have a choice -- so of course the dictator
devs wouldn't like or want this.  Users are to be trodden upon and forced
to conform to what devs think they should do.  So much for user-friendly
and programs being to help users vs. oppressed by them.


On 12/20/2018 4:48 PM, Paul Eggert wrote:
> If the behaviors you want cannot be done now via command-line options, 
> that's not an argument against configuring via PATH; it's merely an 
> argument that you would like some random features that the programs 
> don't provide now.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.