XDG_CONFIG_DIRS an /usr/local/etc/xdg

Bollinger, John C John.Bollinger at STJUDE.ORG
Mon Sep 20 18:55:52 UTC 2021


Again, Peter, what are you looking for at this point?

Perhaps you misunderstand the nature of this forum.  It is a general discussion list, not a communications portal to a standard-setting body.  I'm sorry if you feel frustrated with the response you have received, but feel free to chalk it up to us being a bunch of clueless idiots, too young / stupid / inexperienced / biased / whatever to understand you.  After all, none of us understand netiquette like you do.

Do you want an "Oh, yes, you're so right!"?  It doesn't look like that's coming.

Do you want a "Sure, we'll change (or withdraw) the spec"?  That's not within our power.

Do you want to talk about what BaseDir actually says and what it doesn't, and how to deal with that?  We might be able to help you on that one.


Regards,

John

-----Original Message-----
From: xdg <xdg-bounces at lists.freedesktop.org> On Behalf Of Peter White
Sent: Monday, September 20, 2021 11:03 AM
To: xdg at 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 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.

________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer


More information about the xdg mailing list