XDG_CONFIG_DIRS an /usr/local/etc/xdg

[Peter White]

On Mon, Sep 20, 2021 at 05:37:02PM -0400, Eli Schwartz wrote:
> On 9/20/21 12:03, Peter White wrote:
> > The way I see it there will be two universes: FHS and a subtly different
> > XDG Base Dir Spec, which breaks with the former in peculiar subtle ways
> > and any dev used to the former is in for some surprises, when not
> > reading carefully. Now, I get that by saying "information" instead of
> > "files" the authors did not want to limit themselves or the spec to
> > files, which makes sense, given the elaborations about reading config
> > files, let aside that it has been done since long before XDG anyways by
> > shells for example. I think some people would do good by reading and
> > understanding what was there already before "fixing" things that were
> > not broken in the first place. This "information" vs. "files" stuff
> > seems like one of these occasions.
> > 
> > [...]
> > 
> > There is no need for a new spec to make this happen since this is
> > documented in shell manuals which were there from the beginning of time,
> > UNIX time that is.
> > 
> > And, need I remind anyone: "Those who do not understand UNIX are
> > condemned to reinvent it, poorly." -- Henry Spencer
> > A lot of thought went into it, so one should not go fixing stuff that
> > was never broken.
> 
> 
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
> 
> Did you say something about the sacred Unix? Who is reinventing what now?

Nice read, the point being? ;) I am not talking about "the split" and
/usr/local *is* specified and does make a whole lot of sense in FHS. And
that author does not understand what /opt is actually for, but that is
very much off-topic, so I won't digress any further. FHS is always a
good read, when in doubt. And there never was a need for *another* spec
that breaks its override characteristic. At least I fail to see it, and
nobody, so far, could provide a good reason for it. If there is need
for, say, *additional* data dirs, then specify *those* and do *not* make
XDG_DATA_DIRS default to /usr/local/share:/usr/share, since those are
already covered by FHS, which differs subtly but very significantly in
what happens if files with the same name exist in both, as I tried to
point out. FHS: file /usr/local/share/foobar masks /usr/share/foobar,
while, XDG mandates to also check /usr/share/foobar for information not
present in the former.

Same goes for XDG_CONFIG_DIRS: if it weren't for the default (/etc/xdg)
all could be just fine. Yes, do encourage anything that is remotely
related to desktop software to expect/put the *least* important config
file(s) in ${PREFIX}/etc/xdg/<appname>, but leave XDG_CONFIG_DIRS empty
with *no* default, the app should just hardcode the expected location at
compile time. If the user/admin *then* has additional needs, they can go
nuts with XDG_CONFIG_DIRS, for all I care. Again, there is no equivalent
env var for the good old ${PREFIX}/etc, because that location is so well
known and documented that, for all intents and purposes, it *can* be
hardcoded, and that is what non-XDG apps have always done.

So, staying in my ealier example, which I want to clarify in (some) more
detail here:

1. Read ${PREFIX}/etc/xdg/<appname>/<rcfile(s)>, if it/they exist(s).
2. Read in reverse order, so as to go from least important to most
important, files in XDG_CONFIG_HOME, if it is set, move on otherwise.
DO NOT DEFAULT to anything.
3. Read XDG_CONFIG_HOME.
(Since most important information is read and set last, the condition
that it takes precedence is satisfied)

This is pretty much what already happens with *any* software I can think
of, but shells are very good examples, since they tend to document this
very clearly. The *only* addition the spec needs, or needed rather, was
XDG_CONFIG_DIRS but not the default.


Best,
PW