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-boun...@lists.freedesktop.org> On Behalf Of Peter White
Sent: Monday, September 20, 2021 11:03 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 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
