Dear John,
would you please reply on the list, it being the only recipient? By
putting me first, I don't get the list headers cannot do a proper list
reply.
On Thu, Sep 16, 2021 at 05:38:37PM +0000, Bollinger, John C wrote:
> 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.
And that should not be an issue. This feels like a huge regression to
the tried and tested way I described. Have a look at the Filesystem
Hierarchy Standard which predates XDG by a huge margin. All the
admin/user *should* have to do is making sure that they run the
appropriate binary by either manipulating path or running by specifying
the absolute path to the binary explicitly.
> 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.
Yes, and that would make it an oversight, as I suggested in my initial
message. ;) Because, how do you make use of facilities like, i.e.
g_get_system_config_dirs() in a program in a portable way if the
simplest of all installation methods (make install) is not accounted
for?
> 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.
Well, again, that rules out *any* use of XDG_CONFIG_DIRS or the helper
functions querying it at *runtime*, because one must check at compile
time anyway and if that is the case one can just as well not use it at
all. Maybe it is useful to check at compile time if the target distro
prefers other locations and just prepend PREFIX to that, so
${PREFIX}/etc is consistent with what the distro does in /etc.
> 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.
I am not talking about multiple versions in the same PREFIX. I am
talking about the tried and tested way of having one version in /usr and
/usr/local each.
Best,
PW
