Hi
On 16/03/16 00:58, Cosimo Cecchi wrote:
Hi Ikey,
On Mon, Mar 14, 2016 at 6:32 AM, Ikey Doherty
<[email protected] <mailto:[email protected]>> 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
_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg
