XDG_CONFIG_DIRS an /usr/local/etc/xdg

[Peter White]

On Mon, Sep 20, 2021 at 02:09:00PM +0000, Bollinger, John C wrote:
> So what are you looking for at this point, Peter?  I think we're well
> past any question of interpreting the details of the spec, and we've
> even delved a bit into its history and design goals and its intended
> usage model.

While I value your input I cannot judge your authority on this. And a
newer spec should not break prior art in such (subtle) ways, see
"information" as opposed to "files" vis-a-vis XDG_DATA_DIRS and FHS, for
example.

> We get that you are unhappy about how its use interacts
> with certain software installation scenarios that you care about, but
> the Base Directory spec is not going to be changed in a way that would
> satisfy you because the result would no longer be recognizable as Base
> Directory.

It still could, you just fail to acknowledge my suggestions. It does not
even have to be a hard change on the /etc/xdg stuff. A simple guideline
as to when to use XDG_CONFIG_DIRS to find "information" and when *not*
to would suffice. Again, no application should need to guess where its
config is expected to be at runtime. There simply is no need for this.

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.

Let me outline this once more, i.e. on XDG_CONFIG_DIRS usage for
information *not* directly related to the app (again: the should know
where to expect its own, so do not *abuse* this facility for that):

1. Concatenate all relevant config files found in XDG_CONFIG_DIRS and
XDG_CONFIG_HOME, ordered by importance from *least* important to *most*
important, i.e. reverse the order of XDG_CONFIG_DIRS and put
XDG_CONFIG_HOME last.
2. Work your way from top to bottom, as in *least* important to *most*
important and set values as they come, overwriting blindly what was set
before, because any later occurrence is *more* important.
3. Done!

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.

Given the above, should the spec really insist on "information" rather
than files? The share/ hierarchy was and still is in FHS, no need for
duplication. Fix the stuff it does *not* talk about or rather improve on
that basis, like XDG_CONFIG_HOME to reduce the dotfile proliferation. I
very much welcome and appreciate that. But do not change the semantics
of how it works: first *file* match wins, ignoring all others, hence the
override characteristic which is expected from /usr/local.

Plus--I am repeating myself, I know--there is no need to get more
granular than down to the file level. See also my suggestion for
exporting config setting pertaining to the environment, i.e.
	$ cat $XDG_RUNTIME_DIR/xdg/<appname>/<settings>/<key>
	value

Call it xdgfs, if you will. And there, we are back to the good old:
"Everything is a file.", and there really is no need to get more
granular, just use more files if you need to, they are very cheap. ;)

And the only change needed to get the outlined behaviour is: telling
people how.  Not everybody is an expert and the project that I have in
mind started as a hobby (weekend) project, XDG being a late
afterthought. I am not even sure if XDG was already conceived by that
time.

So, /etc is some kind of a special case as to "information", since one
usually expects every relevant file to be taken into account, see above
about shell init. But, again, clarify what is meant by "information" in
what context. I seriously doubt that devs use
/usr/local/share:/usr/share the way the spec seems to intend, meaning
that they really go on and read the *less* important files (same name in
a less important location) to see if there is "information" the most
important match does not have. So far, from my limited perspective, they
just use it as outlined in FHS: stop after finding the *most* important
match.
If I am mistaken, name one example *and* explain why it cannot be done
the "old-school" way, please.

> And clearly, although I'm sure we will all acknowledge
> that BD does not serve every conceivable scenario satisfactorily,
> there is no general sentiment that that constitutes a major flaw in
> the spec.

Please don't give me that there is downsides to everything stuff,
seriously. I see that the horse is out the barn and closing the door now
is pointless. But the spec is still not finished (v0.8), so there is
still time to fix or even just clarify the worst misunderstandings.


Best,
Peter

P.S.: And again I urge you not to "fix" my line breaks. See my longer
reply to Elsie. And *do* *not* *top-post*, for crying out loud.  You are
the one not even respecting netiquette and want to talk to me about
(not) "fixing" stuff?! I am very sorry, but now I am nonplussed, to say
the least.