Heads-up: Linux make menuconfig .config vs. XDG_CONFIG_HOME ~/.config/ clash - perhaps resolve it while 3.0 appears?

Heads-up: Linux make menuconfig .config vs. XDG_CONFIG_HOME ~/.config/ clash - perhaps resolve it while 3.0 appears?

[Andreas Mohr]

Hello all,

I just discovered a Linux kernel make menuconfig .config file
accidentally situated in the home directory of a shell account
(simply scp:d over without much thought, thus directly ending up in main
user home on that machine, something which can happen quite easily
for a number of other reasons as well).
I then realized the potentially fatal ramifications of this.

XXXXXX:/tmp$ touch mytest
XXXXXX:/tmp$ mkdir mytest
mkdir: cannot create directory `mytest': File exists


XDG Base Directory Specification
  http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
says:

"$XDG_CONFIG_HOME defines the base directory relative to which user
specific configuration files should be stored. If $XDG_CONFIG_HOME is
either not set or empty, a default equal to $HOME/.config should be
used."
And that mechanism is exactly what a ton of Linux userspace apps
(and hopefully many more in future) are already making use of
to store their configuration data in a manner
that's more friendly to user home directories.


It may thus be strongly advisable to rename the default name of the
make menuconfig kernel .config file (perhaps .config_lx / .config_linux ?)
to completely sidestep such a (mostly user-triggered)
problematic clash in future.

And (I cannot help but think of this) now that lx 3.0 is in -rc
this might still be an especially appropriate moment to do it ;)
(one would have to think of potential compatibility issues though)

Thanks for listening,

Andreas Mohr

Re: Heads-up: Linux make menuconfig .config vs. XDG_CONFIG_HOME ~/.config/ clash - perhaps resolve it while 3.0 appears?

[Michal Marek]

On 2.6.2011 20:24, Andreas Mohr wrote:
> I just discovered a Linux kernel make menuconfig .config file
> accidentally situated in the home directory of a shell account
 > [...]
> "$XDG_CONFIG_HOME defines the base directory relative to which user
> specific configuration files should be stored. If $XDG_CONFIG_HOME is
> either not set or empty, a default equal to $HOME/.config should be
> used."

PEBKAC :-). BTW, did you really run into such problem yourself, or is it 
more a "what if"?


> It may thus be strongly advisable to rename the default name of the
> make menuconfig kernel .config file (perhaps .config_lx / .config_linux ?)
> to completely sidestep such a (mostly user-triggered)
> problematic clash in future.

No. The name ".config" is documented in the linux source as well as so 
many howtos and books, that we should not change it just for the fun of 
it. Arguably, a non-dot filename might have been a better choice, but 
".config" has been chosen, so we have to live with it.


> And (I cannot help but think of this) now that lx 3.0 is in -rc
> this might still be an especially appropriate moment to do it ;)

Linus made it clear that 3.0 is just a change in versioning, not an 
excuse for doing incompatible changes. (Incompatible changes can 
possibly happen in any release, but they need to be justified and need 
to be ready *before* -rc1.)

Michal

Re: Heads-up: Linux make menuconfig .config vs. XDG_CONFIG_HOME ~/.config/ clash - perhaps resolve it while 3.0 appears?

[Andreas Mohr]

On Fri, Jun 03, 2011 at 10:25:46AM +0200, Michal Marek wrote:
> On 2.6.2011 20:24, Andreas Mohr wrote:
> >I just discovered a Linux kernel make menuconfig .config file
> >accidentally situated in the home directory of a shell account
> > [...]
> >"$XDG_CONFIG_HOME defines the base directory relative to which user
> >specific configuration files should be stored. If $XDG_CONFIG_HOME is
> >either not set or empty, a default equal to $HOME/.config should be
> >used."
> 
> PEBKAC :-). BTW, did you really run into such problem yourself, or
> is it more a "what if"?

"Yes and no." ;)
I did have that file sitting where it should better never have ended up
given its naming, thus I obviously did not have any .config/ directory there
at all (as opposed to a usual installation where .config/ already contains
many entries).
I had started by actively searching for contents of the .config/ dir there,
then found that there's only a .config _file_, which made me realize
that this can be very problematic.
It's unknown to me whether any friendly bits have already actually been hurt
by this problem - unless an app complains loudly, the only thing
one might perhaps notice is strange behaviour of various apps.


It's just that I feel that this is quite a major naming clash.

 
> >It may thus be strongly advisable to rename the default name of the
> >make menuconfig kernel .config file (perhaps .config_lx / .config_linux ?)
> >to completely sidestep such a (mostly user-triggered)
> >problematic clash in future.
> 
> No. The name ".config" is documented in the linux source as well as
> so many howtos and books, that we should not change it just for the
> fun of it. Arguably, a non-dot filename might have been a better
> choice, but ".config" has been chosen, so we have to live with it.

So we'll have to live with that on the other side (i.e., XDG) as well?
(which, I'm sure, will have its $HOME/.config/ directory documented in
_even more_ application-side documentation prints than the Linux
kernel .config file).
The nature of clashes is just that - it's a problematic clash,
thus it may be very helpful to devise a cleanly implementable
(read: backwards-compatible and such) exit strategy.

A change from .config to e.g. .config_linux would not be such a foreign
thing, given that it wwould be found at the very same place as the old name
in most file-manager-type situations (thus RL people wouldn't be left
wondering for all that long). One actual source of concern would be
existing scripts which by their nature currently make use of a hard-coded lookup
on ".config", as opposed to manual human action which would easily take note
of the .config_linux file.



To put forward a deeper analysis:
I guess the rationale for choosing an XDG ".config/" was to be the
singular remaining place for configuration items within a user's home
dir. Thus there's no need (nor even desire!)
to have any naming that's more specific than ".config",
since this mechanism is supposed to be as generic as it can get.

For the case of the naming of the Linux kernel configuration file?
- not so much, I'd say.
The main remaining justification for this overly generic name is
that it's supposed to sit in its own isolated kernel source dir,
and that as long as this is the case it's not conflict-prone.

Thus quite obviously I followed neither the letter of the law, nor agreed
conventions, nor all unspoken rules and conditions,
by copying the file to a _default_ place where it shouldn't end up. ;)
[and thus I'll incur the terminal wrath of all configuration gatekeepers]



Just to mention this here as well: of course it might be more suitable
to choose a filename which is using the usual *.conf extension recommendation.


> Linus made it clear that 3.0 is just a change in versioning, not an
> excuse for doing incompatible changes. (Incompatible changes can
> possibly happen in any release, but they need to be justified and
> need to be ready *before* -rc1.)

Absolutely fine with that (I was even quite astonished myself about that
relatively ad-hoc numbering change).
It just occurred to me that it might be worth mentioning this
as an appropriate moment to be doing this change in addition
to the version change.

Thanks,

Andreas Mohr

Re: Heads-up: Linux make menuconfig .config vs. XDG_CONFIG_HOME ~/.config/ clash - perhaps resolve it while 3.0 appears?

[Nick Bowler]

On 2011-06-02 20:24 +0200, Andreas Mohr wrote:
> "$XDG_CONFIG_HOME defines the base directory relative to which user
> specific configuration files should be stored. If $XDG_CONFIG_HOME is
> either not set or empty, a default equal to $HOME/.config should be
> used."
[...]
> It may thus be strongly advisable to rename the default name of the
> make menuconfig kernel .config file (perhaps .config_lx / .config_linux ?)
> to completely sidestep such a (mostly user-triggered)
> problematic clash in future.

If a program can't create its config directory or file(s), presumably it
will display an error message to that effect and the user can correct the
problem: after all, this scenario only occurs when the user puts a
kernel .config file in their home directory.  I imagine that a user
which is capable of doing such a thing is also capable of deleting
files.

Furthermore, Once the ~/.config directory has been created (by running
any program that does so), this problem cannot occur.

There are many other reasons that a program might fail to access its
configuration data.  I suspect that "no space remaining" or "read-only
filesystem" are more likely than "oops, I managed to put a .config file
in my home directory before running a single program that created
~/.config/".

Administrators can prevent hapless users from accidentally putting a
.config file in their home directory by creating a .config directory by
default.  Distros could help here by putting an empty .config directory
in /etc/skel.

Renaming the .config file is obviously going to cause a lot of pain, and
there seems to be very little gain.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: Heads-up: Linux make menuconfig .config vs. XDG_CONFIG_HOME ~/.config/ clash - perhaps resolve it while 3.0 appears?

[Arnaud Lacombe]

Hi,

On Fri, Jun 3, 2011 at 10:38 AM, Nick Bowler <nbowler@elliptictech.com> wrote:
> Renaming the .config file is obviously going to cause a lot of pain, and
> there seems to be very little gain.
>
For the record, it is already possible to rename the config file
through the KCONFIG_CONFIG environment variable:

Documentation/kbuild/kconfig.txt:

KCONFIG_CONFIG
--------------------------------------------------
This environment variable can be used to specify a default kernel config
file name to override the default name of ".config".

 - Arnaud