Dear Peter, What XDG Base Directory does not particularly contemplate is that there might be a collision between the config or data file names relied upon by different applications (including different versions of the same application). Again, this has nothing in particular to do with how applications are packaged or delivered, or with where or how they are installed. The issue could as easily affect multiple vendor-supplied packages or multiple from-source installations to /usr/local the same way it does mixes of those. It could affect pairs of altogether distinct applications, too.
You may consider this a flaw in the spec if you prefer, but I just consider the scenario to be outside Base Directory's scope. It is not a problem that BD intends to address. To the extent that it sometimes has particular impact on the concurrent installation of multiple versions of the same application, I think it more appropriate to attribute that to the application involved. One thing that some Linux distributions do when they provide concurrently-installable packages of different versions of the same software is to configure or patch one or more of them to include a version number in their config file names. This resolves the name collision, allowing each version to find the correct config and data files, and it is in no way specific to software packages or installation location. And of course there are ways to accommodate multiple installations that do not require patching or special configuration. The list in my first response covered some of these. Inasmuch as supporting multiple concurrent installations is rarely a characteristic to which software developers attribute much importance, you should not be surprised if it takes extra work on the install side to accommodate that. Regards, John -----Original Message----- From: xdg <xdg-boun...@lists.freedesktop.org> On Behalf Of Peter White Sent: Thursday, September 16, 2021 11:49 AM To: xdg@lists.freedesktop.org Subject: Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg Caution: External Sender. Do not open unless you know the content is safe. On Thu, Sep 16, 2021 at 04:15:07PM +0000, Bollinger, John C wrote: > The value of XDG_CONFIG_DIRS, if set, is expected to be a string > designating one or more directories to search for config files, in > priority order. If multiple directories are specified then they are > separated by colon characters (:). This represents a search path, > similar to the executable search path conveyed via $PATH. > > HOWEVER, Base Directory does not specify a first match wins rule. It > attributes more importance (the spec's terminology) to files located > in earlier directories in the list, but that does not imply that only > one can be used. Fair point, I was talking about "information" as opposed to files. Then the first match wins is exactly the same as your description. ;) But, /etc should be off limits for software in /usr/local, right? So XDG_CONFIG_DIRS has a hole in the spec, because one cannot set it up so that distro software _and_ software in /usr/local do the right thing, because whatever is set as "more important" wins for both. Or, as I said, maybe it should not be used like this to begin with? But then, what is its *intended* use? > At least a limited ability to merge multiple configs is suggested by > the provision for XDG_CONFIG_HOME, which designates a user-specific > search directory of even higher importance that, alone among all > these, is assumed to be writable by the user. This latter is where a > user would record their personal config customizations, and a > user-friendly application with many configuration options will not > insist that users provide a complete configuration just to customize a > few items. That is a very good point. The software in question currently does the latter, but I think this is out of scope for my initial question. I can live with a first match wins rule on file basis, for the time being. Best, PW ________________________________ Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer
