<div dir="ltr">Hi Ikey,<div><br></div><div>On Mon, Mar 14, 2016 at 6:32 AM, Ikey Doherty <span dir="ltr"><<a href="mailto:michael.i.doherty@intel.com" target="_blank">michael.i.doherty@intel.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Therefore I propose that XDG_CONFIG_DIRS is extended to also support<br>
a new vendor location:<br>
<br>
/usr/share/xdg<br>
<br>
It is also proposed on the glib bug linked below that we could extend<br>
support for "/run/xdg" also for systemd-style runtime trees.<br>
<br>
Notably, this is within the $(datadir) and *not* $(sysconfdir).<br>
It should also have a lower priority than the existing $(sysconfdir)/xdg<br>
directory, which in all cases should be respected as a local system-wide<br>
*override* to the vendor directory.<br></blockquote><div><br></div><div>I completely agree with the principle behind this proposal, and would love to see a change along those lines.</div><div>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.</div><div><br></div><div>In other words, what does putting the new directory in XDG_CONFIG_DIRS give us compared to changing affected applications?</div><div><br></div><div>Cheers,</div><div>Cosimo</div></div></div></div>