Proposal: Stateless configuration by extending XDG_CONFIG_DIRS
michael.i.doherty at intel.com
Wed Mar 16 01:48:36 UTC 2016
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:
> 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?
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
autostartdir = $(sysconfdir)/xdg/autostart
autostart_DATA = myfile.desktop
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 :))
More information about the xdg