Proposal: Stateless configuration by extending XDG_CONFIG_DIRS

[Ikey Doherty]

Hi

On 16/03/16 00:58, Cosimo Cecchi wrote:
> Hi Ikey,
>
> On Mon, Mar 14, 2016 at 6:32 AM, Ikey Doherty
> <michael.i.doherty at intel.com <mailto:michael.i.doherty at intel.com>> wrote:
>
>     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.
>
>
> 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