Proposal: Stateless configuration by extending XDG_CONFIG_DIRS

[Ikey Doherty]

Hello,

I would like to propose extending the current range of XDG_CONFIG_DIRS
to support stateless operating systems.

In a stateless operating system, the /usr tree is considered to be the
domain of the vendor, i.e. the OS files themselves. Files in /etc/ and
/var, i.e. mutable nodes in the filesystem, are considered to be owned
exclusively by the local system administrator (i.e. unix account euid 0)

In order to keep these split-domains, vendor-provided files must then
not violate this specification, and must instead provide files in the
/usr tree (This is under the assumption of course that the Operating
System no longer has a split /usr / tree.)

Therefore I propose that XDG_CONFIG_DIRS is extended to also support
a new vendor location:

/usr/share/xdg

It is also proposed on the glib bug linked below that we could extend
support for "/run/xdg" also for systemd-style runtime trees.

Notably, this is within the $(datadir) and *not* $(sysconfdir).
It should also have a lower priority than the existing $(sysconfdir)/xdg
directory, which in all cases should be respected as a local system-wide
*override* to the vendor directory.

Many benefits come from this approach: a less poluted /etc/ tree, a
complete domain-split between OS files and local system administrator
files, and no longer having to perform so-called "three-way merge" on
the local $(sysconfdir) files vs the vendor-provided OS files.

For the relevant glib discussion, please see:
https://bugzilla.gnome.org/show_bug.cgi?id=763539

For a larger discussion on this topic, please see:
https://clearlinux.org/features/stateless

This has already been implemented in the Clear Linux Project for Intel
Architecture, and as such converging on a standard now that the work
has been shown to work and be beneficial, would help all parties
moving forward into a more stateless era.

Many thanks,

- Ikey Doherty

[Cosimo Cecchi]

Hi Ikey,

Post by Ikey Doherty
Therefore I propose that XDG_CONFIG_DIRS is extended to also support
/usr/share/xdg
It is also proposed on the glib bug linked below that we could extend
support for "/run/xdg" also for systemd-style runtime trees.
Notably, this is within the $(datadir) and *not* $(sysconfdir).
It should also have a lower priority than the existing $(sysconfdir)/xdg
directory, which in all cases should be respected as a local system-wide
*override* to the vendor directory.

I completely agree with the principle behind this proposal, and would love
to see a change along those lines.
On the other hand, I wonder whether adding /usr/share/xdg to
XDG_CONFIG_DIRS is really the correct thing to do; applications will need
to be changed to install their default configuration in the new directory,
and there are programs out there (e.g. systemd) that already implement /etc
overrides and /usr vendor defaults.

In other words, what does putting the new directory in XDG_CONFIG_DIRS give
us compared to changing affected applications?

Cheers,
Cosimo

[Ikey Doherty]

Hi

Post by Cosimo Cecchi
Hi Ikey,
On Mon, Mar 14, 2016 at 6:32 AM, Ikey Doherty
Therefore I propose that XDG_CONFIG_DIRS is extended to also support
/usr/share/xdg
It is also proposed on the glib bug linked below that we could extend
support for "/run/xdg" also for systemd-style runtime trees.
Notably, this is within the $(datadir) and *not* $(sysconfdir).
It should also have a lower priority than the existing $(sysconfdir)/xdg
directory, which in all cases should be respected as a local system-wide
*override* to the vendor directory.
I completely agree with the principle behind this proposal, and would
love to see a change along those lines.
On the other hand, I wonder whether adding /usr/share/xdg to
XDG_CONFIG_DIRS is really the correct thing to do; applications will
need to be changed to install their default configuration in the new
directory, and there are programs out there (e.g. systemd) that already
implement /etc overrides and /usr vendor defaults.
In other words, what does putting the new directory in XDG_CONFIG_DIRS
give us compared to changing affected applications?
Cheers,
Cosimo

The immediate benefit is that all applications currently scanning
the XDG_CONFIG_DIRS are immediately compatible, as an example
all glib using packages would have no changes required.

As for *shipped* data, yet this would require modification from the
usual:

autostartdir = $(sysconfdir)/xdg/autostart
autostart_DATA = myfile.desktop

to

autostartdir = $(datadir)/xdg/autostart

i.e. a one-line diff in the vast majority of cases. Where it becomes
less simple is where we find applications hard-coding absolute
paths to these .desktop files, a number of examples can be found
in XFCE. However this then becomes a 2/3-line diff so no biggy..

I still believe XDG_CONFIG_DIRS is the correct location for it
in terms of respecting both backwards *and* forwards compatibility,
enabling vendor-adoption without causing large breakage due to
moving session files and such. (And menus, etc.)

Also note that XDG_CONFIG_DIRS isn't explicitly writable by
nature for any user other than euid 0 when it already includes
/etc/xdg in the path, a system-wide location.

However there is also the aspect that what have long been
deemed config files, actually, are not. In the instance of
$(datadir)/xdg/autostart/app.desktop, my belief is that
those respecting a newer spec would allow disabling system-wide
of said autostart with something like:

$(sysconfdir)/xdg/autostart/app.desktop -> /dev/null

Similar in nature to how we see services masked in systemd.

For the case of semantics we could argue that XDG_VENDOR_DIRS
was more appropriate, however there remains the issue of
forwards compatibility for older applications on these
newer-spec-conformant systems (Not to mention a doubled
char** traversal :))

- ikey

[David Faure]

Post by Ikey Doherty
Hello,
I would like to propose extending the current range of XDG_CONFIG_DIRS
to support stateless operating systems.
In a stateless operating system, the /usr tree is considered to be the
domain of the vendor, i.e. the OS files themselves. Files in /etc/ and
/var, i.e. mutable nodes in the filesystem, are considered to be owned
exclusively by the local system administrator (i.e. unix account euid 0)
In order to keep these split-domains, vendor-provided files must then
not violate this specification, and must instead provide files in the
/usr tree (This is under the assumption of course that the Operating
System no longer has a split /usr / tree.)
Therefore I propose that XDG_CONFIG_DIRS is extended to also support
/usr/share/xdg
It is also proposed on the glib bug linked below that we could extend
support for "/run/xdg" also for systemd-style runtime trees.
Notably, this is within the $(datadir) and *not* $(sysconfdir).
It should also have a lower priority than the existing $(sysconfdir)/xdg
directory, which in all cases should be respected as a local system-wide
*override* to the vendor directory.
Many benefits come from this approach: a less poluted /etc/ tree, a
complete domain-split between OS files and local system administrator
files, and no longer having to perform so-called "three-way merge" on
the local $(sysconfdir) files vs the vendor-provided OS files.

No objection, sounds reasonable.

Just the directory name is a bit strange, I would have expected /usr/share/config
or /usr/share/xdg-config. Otherwise nothing says "config" anymore, /usr/share/xdg looks
like it could be anything.

Next step is to make a patch for the spec in git?