Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Mon, Sep 20, 2021 at 06:14:49PM -0400, Elsie Hupp wrote: > > I find it intriguing that you insult people > > right back by calling an *extremely* common convention in technical > > mailing lists, a "dusty cultural artifact" and suggesting that it is > > malicious behavior. > > I’ve been using email for 25+ years. (I have people twice my age and people > half my age find my technical generation incomprehensible.) Blockquotes have > always been annoying and awful, but they had stopped being a constant thorn > in my side until I joined this mailing list. They don’t even seem to be a > problem on other mailman mailing lists I’m on. > > > a “dusty cultural artifact” > > Yes, this is a thing called “shade”. > > > I am sure we are all delighted to know that disagreeing over mailing > > list etiquette "with intent to make smartphones do worse rendering of > > the messages" is the point at which you believe it is necessary to > > summon the code of conduct committee in order to report > > passive-aggressive condescension. > > Oh, the problem was that that *dude* ... > > I CC’d the conduct committee So did I just now. How is *your* behaviour compliant with said CoC?! All of a sudden the gloves came of it seems. How is it OK to call anyone "that dude"? Do you think I cannot read this or contact the CoC committee about it? > This was the third or fourth response where he had been lecturing me > personally over nothing at all. When did I lecture you?! I gave you *one* hint and you come back with *that* attitude? From now on I will simply ignore you, but I very much demand action from the CoC team regarding *your* conduct!
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
Correction, sorry I just noticed: On Mon, Sep 20, 2021 at 11:49:31PM +, Peter White wrote: > 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. +> important, files in XDG_CONFIG_DIRS, if it is set, move on otherwise. > DO NOT DEFAULT to anything. Of course that needs to be XDG_CONFIG_DIRS. m( Best, PW
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Mon, Sep 20, 2021 at 03:04:39PM -0400, Elsie Hupp wrote: > Mr. White, > > You write: > > > Be that as it may, one should not have to resort to such rather > > extreme measures just to get sane behaviour back. And please stop > > drumming for Flatpak. It does have its application but not for this. > > I mean, come on, more layers of complexity just for this. Plus all > > the downsides I do not want to discuss here, since they are out of > > scope > > Flatpak is a major—and standards-compliant—implementation of > XDG_CONFIG_DIRS, alongside GNOME, KDE, etc. And then some, or do you seriously want to tell me that that is *all* there is to it? I am talking 'make && sudo make install' which is the simplest, easiest and fastest way to get upstream software running for testing. > And you haven’t actually specified what your use case is; you’ve been > consistently vague Which is very much intentional, since it should not matter. The use case of installing software to the very well known prefix /usr/local and it overriding the *less* important version in /usr is sufficient to outline the problem. And I do not want to go into specifics since the original authors of an actual example at hand, which started me off, might not want to be named and again, it should not matter. > in a way that allows your text to maintain an unearned tone of > righteousness and moral superiority. I am very sorry, if you genuinely feel that way. I was and still is not my intention. I try to be courteous and even put a smiley here and there to make clear that this, while passionate, comes from a friendly position and I am genuinely interested in improving things, since it has been said, by others too, that there is an oversight in the spec. But I will try to improve on that. Just let me add, that I am not a native speaker, so I may not always hit the right tone, simply because I do not know *all* about the language, and I somewhat dislike excessive use of emoticons and hence try to use them sparsely. OFF-TOPIC: > You write: > > > Yes, that is very much intentional, those are not “soft-wrap” but > > real line breaks. You should read up on mailing list netiquette if > > this is news to you. Yes, there is an RFC for that, and please don’t > > go “fixing” my text. > > As far as I know RFC 1855 is not part of any accepted email > specification—i.e. the ones actually used by the more popular email > clients—and several of the behaviors encouraged in it lead to > undefined behavior on adaptive devices that did not exist in 1995, > such as smartphones. I am very sorry about that, but I won't change this, because then someone else will feel offended. This *is* what is expected on mailing lists and I do not want to get downgraded or ignored for being ignorant of style. Please also note that I am not alone in this, since rhkra...@gmail.com seconded my prior hint at the netiquette to John Bollinger. > Intentionally using formatting that breaks on the vast majority of > computing devices in use is not “good etiquette”; this behavior is > pedantic, condescending, and passive-aggressive, all attributes that > directly violate the Freedesktop Community Standards, which are a much > more important document than your dusty cultural artifact: Those clients and devices should be fixed. I do not break anything *intentionally* as this is what I believe is the expected behaviour on any mailing list. And there are lists, where you would get burned for ignoring said RFC. And all I did, was giving a *friendly* as to why. I even offered to make my default line length only 65 characters. But instead of replying if that made it better, I get this rather uncalled for response one? I mean, seriously, which device cannot handle 65 characters per line? Should such a device then be ones primary means of mail communication? Smartphones are a compromise on all fronts, so I respectfully refuse to break with well documented and very much expected tradition to accommodate those. Apparently there is no way to please everyone here, anyways. I have made clear why. And I even said, that I *tolerate* if people do not break lines. How is that for: > > Examples of behavior that contributes to creating a positive > > environment include: > > > > • Using welcoming and inclusive language • Being respectful of > > differing viewpoints and experiences • Gracefully accepting > > constructive criticism • Focusing on what is best for the > > community • Showing empathy towards other community members Yes, check all of those. I feel like you just *want* to paint me as the bad guy. And I would very much appreciate it, if smartphone users would not expect the world to revolve around them. > I’m CCing the conduct committee as a way of *gently encouraging you* > to approach this forum in a modicum of good faith. I welcome their perspective. > Note: this is all good-faith, constructive criticism of your behavior, Then why do I get the feeling that it is not
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
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/, 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//, 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
RE: XDG_CONFIG_DIRS an /usr/local/etc/xdg
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 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 +, 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/// 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 b
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
> I find it intriguing that you insult people > right back by calling an *extremely* common convention in technical > mailing lists, a "dusty cultural artifact" and suggesting that it is > malicious behavior. I’ve been using email for 25+ years. (I have people twice my age and people half my age find my technical generation incomprehensible.) Blockquotes have always been annoying and awful, but they had stopped being a constant thorn in my side until I joined this mailing list. They don’t even seem to be a problem on other mailman mailing lists I’m on. > a “dusty cultural artifact” Yes, this is a thing called “shade”. > I am sure we are all delighted to know that disagreeing over mailing > list etiquette "with intent to make smartphones do worse rendering of > the messages" is the point at which you believe it is necessary to > summon the code of conduct committee in order to report > passive-aggressive condescension. Oh, the problem was that that dude took credit for the technical issue and declared it to be righteous and true, all while complaining about a standard nearly as old as the RFC he cited. The irony on top of the irony is that the mangled blockquotes don’t even seem to be his doing; mailman seems to be the one making them terrible for everyone involved. I CC’d the conduct committee so that he wouldn’t respond to me directly. Obviously. Hence the “gently encouraging”. Conduct committees are there for the purpose of dealing with people you don’t want to deal with yourself, even if nobody has really done anything wrong. This was the third or fourth response where he had been lecturing me personally over nothing at all. Also for some reason John’s responses kept ending up in my spam mailbox, so I had gotten six or so green-ink emails in a row with nothing apparently in between them, and I was kind of suspicious this guy wasn’t going to stop on his own.
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On 9/20/21 15:04, Elsie Hupp wrote: > As far as I know RFC 1855 is not part of any accepted email > specification—i.e. the ones actually used by the more popular email > clients—and several of the behaviors encouraged in it lead to > undefined behavior on adaptive devices that did not exist in 1995, > such as smartphones. > > Intentionally using formatting that breaks on the vast majority of > computing devices in use is not “good etiquette”; this behavior is > pedantic, condescending, and passive-aggressive, all attributes that > directly violate the Freedesktop Community Standards, which are a > much more important document than your dusty cultural artifact: The fact that smartphone applications are ill designed is not really an indictment on any particular behavior. They also are lead contenders in behavior such as: - adding advertisements for the app you used into your signature - top quoting the entire email thread, recursively Anyway. Your school of thought is in conflict with another school of thought, both schools of thought have wide support in society, and for someone who is so upset at the thought of people acting "pedantic, condescending and passive-aggressive" I find it intriguing that you insult people right back by calling an *extremely* common convention in technical mailing lists, a "dusty cultural artifact" and suggesting that it is malicious behavior. For the record, my cramped smartphone computing device has no problem rendering Peter's excellently well-formatted quotes, but yours are, to me, unreadable. On the other hand, your non-quote content is *mildly* more readable than Peter's hard line wrapping, but not by very much -- both are relatively quite readable. The real issue that basically destroys my ability to parse your replies is the fact that it's essentially impossible to visually distinguish between quotes and original content. The quotes are just a paragraph beginning with a ">" on the first (reflowed) line only. My desktop client converts both of them to indented blockquotes... but perhaps Google / Gmail doesn't have enough funds to pay for developers as talented as the ones Thunderbird has? I genuinely have no idea, this has always been a real puzzler to me. > I’m CCing the conduct committee as a way of *gently encouraging you* > to approach this forum in a modicum of good faith. > > Note: this is all good-faith, constructive criticism of your > behavior, not your character. As such I’m sure it should be no great > difficulty for you to take it to heart. I am sure we are all delighted to know that disagreeing over mailing list etiquette "with intent to make smartphones do worse rendering of the messages" is the point at which you believe it is necessary to summon the code of conduct committee in order to report passive-aggressive condescension. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
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? -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
Mr. White, You write: > Be that as it may, one should not have to resort to such rather extreme > measures just to get sane behaviour back. And please stop drumming for > Flatpak. It does have its application but not for this. I mean, come on, more > layers of complexity just for this. Plus all the downsides I do not want to > discuss here, since they are out of scope Flatpak is a major—and standards-compliant—implementation of XDG_CONFIG_DIRS, alongside GNOME, KDE, etc. And you haven’t actually specified what your use case is; you’ve been consistently vague in a way that allows your text to maintain an unearned tone of righteousness and moral superiority. You write: > Yes, that is very much intentional, those are not “soft-wrap” but real line > breaks. You should read up on mailing list netiquette if this is news to you. > Yes, there is an RFC for that, and please don’t go “fixing” my text. As far as I know RFC 1855 is not part of any accepted email specification—i.e. the ones actually used by the more popular email clients—and several of the behaviors encouraged in it lead to undefined behavior on adaptive devices that did not exist in 1995, such as smartphones. Intentionally using formatting that breaks on the vast majority of computing devices in use is not “good etiquette”; this behavior is pedantic, condescending, and passive-aggressive, all attributes that directly violate the Freedesktop Community Standards, which are a much more important document than your dusty cultural artifact: > Examples of behavior that contributes to creating a positive environment > include: > > • Using welcoming and inclusive language > • Being respectful of differing viewpoints and experiences > • Gracefully accepting constructive criticism > • Focusing on what is best for the community > • Showing empathy towards other community members If you dislike that the vast majority of the internet has moved on to adaptive text rendering, I suggest you file an RFC about it, or perhaps chain yourself to the front of the Google headquarters. Or, I don’t know, you could use an email client with more normative text rendering? I assume they do, in fact, make ones that work on dialup ANSI terminals. Oh the irony that you’ve expended reams of text complaining about how you don’t like the long-standing XDG folder specification that everyone else seems to accept, right before you turn around and point to an obscure chain letter from the Clinton administration as if it were some sort of inviolable scripture. I’m CCing the conduct committee as a way of *gently encouraging you* to approach this forum in a modicum of good faith. Note: this is all good-faith, constructive criticism of your behavior, not your character. As such I’m sure it should be no great difficulty for you to take it to heart. Sincerely, Elsie Hupp
RE: XDG_CONFIG_DIRS an /usr/local/etc/xdg
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. 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. 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. Regards, John -Original Message- From: xdg On Behalf Of Peter White Sent: Monday, September 20, 2021 8:27 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 08:50:45AM -0400, Elsie Hupp wrote: > > The way you describe it, it would be OK for any app to just parse the > > config of any other. That just feels wrong, because app A should have no > > business snooping in /etc/xdg/B/Brc. If app B wants to make such > > information available to others it should export it instead of requiring > > those to parse the file. > > To be fair, this is one of the motivations behind Flatpak and Snap. If you > don’t want one app snooping where it shouldn’t, then you make it technically > unable to do so. Yes, and then there is XDG which expects exactly that, which then leads to other hacks to soften the isolation of said containers, or the inclusion of files which the go out of sync and out of date compared to what is in the real /etc. If I need hard sandboxing to stop such behaviour, then there is a serious bug in the spec. ;) Best, PW P.S.: Please do not attach the whole history. Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Mon, Sep 20, 2021 at 03:28:09PM +0100, Simon McVittie wrote:
> On Mon, 20 Sep 2021 at 12:28:43 +, Peter White wrote:
> > Why would XDG_CONFIG_DIRS need to contain ${PREFIX}/etc/xdg for that?
> > The app pretty much already knows where it is supposed to find *its own*
> > system-wide config. The location of which *should* be in
> > ${PREFIX}/etc/xdg//, yes, but one does not need to check
> > XDG_CONFIG_DIRS for that at runtime.
>
> If you are an app author and you want to look for defaults, or even
> configuration, in a ${prefix}-relative path, great. Do that! Nobody is
> stopping you from doing that.
>
> However, if you want sysadmins to be able to override the defaults of
> your app on a system-wide basis, or if you want users to be able to
> override the defaults on a per-user basis, they will likely thank you
> for using basedirs at runtime to do that, rather than inventing your
> own mechanism that requires them to set extra environment variables or
> otherwise learn how your app is different.
Nobody said anything about XDG_CONFIG_HOME being ignored. In one of the
first responses I very much clarified, that user config wins, always.
And if the sysadmin wants to override the defaults: edit the rc file in
/usr/local/etc/. There are good reasons for stopping after said
files have been read and reading only those in XDG_CONFIG_HOME
afterwards, explicitly ignoring /etc.
> More concretely, this would be a perfectly reasonable search path to have,
> if you want it;
>
> - $XDG_CONFIG_HOME/myapp/myapprc at runtime
> (per-user overrides, "most important")
> - $dir/myapp/myapprc for each $dir in $XDG_CONFIG_DIRS at runtime
> (user and/or sysadmin overrides)
> - ${sysconfdir}/myapp/myapprc for compile-time ${sysconfdir}
> (installation-specific configuration)
> - ${datadir}/myapp/myapprc for compile-time ${datadir}
> (fallback/defaults, "least important")
And basically you have it backwards. See my other post about a dead
simple way of reading configs that has been around for ages: read the
*most* important file *last*. That saves you from any fancy "merging" of
config files, because it is a cheap side effect of that approach.
The only thing that I do not want, is the sysconf of the distro version
being read.
> If you did something like that, it would work equally well for
> --prefix=/usr/local and --prefix=/opt, and still allow users and sysadmins
> to override the settings for myapp the same way they're familiar with for
> other apps.
Again, see my worst case of there being an obsolete setting in /etc/xdg
and a new (formerly illegal) one in /usr/local/etc/xdg, which could DoS
both versions.
> > It would make sense, though, to query XDG_CONFIG_DIRS at *compile time*
>
> I don't think that makes sense. The point of environment variables is that
> they are runtime-variable.
Yes, at *make* runtime. :-P But it does not make a whole lot of sense
*guessing* or asking, rather, where to find *my* config, especially when
there is no (spec compliant) way to only use the local version, since it
(XDG BD) very much demands "information" in less important locations be
considered as well. See the setting being obsolete and hence missing in
/usr/local/etc/xdg... but still in active use and necessary in /etc for
the older distro version.
To reiterate again, /usr/local is expected to override /, by
masking/overruling files which are present in both. First file match
wins, ignore the less important one(s).
> > And the more I think about it *and* seeing that no-one seems to ever set
> > XDG_CONFIG_DIRS, which then defaults to /etc/xdg, this variable could
> > just as well be renamed to the singular version XDG_CONFIG_DIR and only
> > contain *one* value
>
> No, that would be an incompatible change that would break pre-existing,
> working configurations.
> > There is only one XDG_CONFIG_HOME as well.
>
> XDG_CONFIG_HOME has a dual role: it's the highest-precedence configuration
> directory, and it's the place that automated per-user configuration-saving
> saves modified configuration.
>
> It's entirely valid for a user to do something like this:
>
> XDG_CONFIG_HOME=$HOME/.config
> XDG_CONFIG_DIRS=$HOME/dotfiles/xdg:/etc/xdg
>
> with $HOME/.config as the path that is modified automatically when apps
> save their configuration, and $HOME/dotfiles/xdg for configuration that
> the user edits with a text-editor (perhaps stored in a version control
> system).
Interesting approach, thanks for the hint. But I still see no prefix in
there. I am only concerned about system-wide etc/xdg.
To summarize: The only way I see is to either hard code the location of
sysconf(file/dir) or to run local applications through a wrapper that
forces the environment to ignore /etc/xdg, i.e.:
$ env XDG_CONFIG_DIRS=/usr/local/etc/xdg
which is precisely what I would rather avoid, especially since every
user would have to do that on their system, if they compile from
upstream. Or upstream needs to provide said w
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Mon, Sep 20, 2021 at 03:06:06PM +0100, Simon McVittie wrote:
> On Thu, 16 Sep 2021 at 04:44:17 +, Peter White wrote:
> > I am having a hard time finding documentation about the best way to make
> > locally installed software recognize its config dir in
> > /usr/local/etc/xdg.
>
> One high-level approach to this is: give it sensible defaults, so that it
> will work correctly with an empty /etc, and don't install anything to
> ${sysconfdir}/etc/xdg from the package's build system.
This seems orthogonal to the problem at hand. I usually expect an rcfile
in /etc, or /usr/local/etc for that matter, as an editable working
"example". There are apps that have different defaults than are set in
the shipped config files residing in /etc.
> (Those defaults can be in a file in ${datadir} with the same syntax as the
> configuration file and a comment that says "do not modify, copy to /etc/xdg
> and modify the copy instead", if you want - that's a common approach.)
Yes, I see that a lot, as in /usr/local/share/doc/ > One might also think:
> >
> > # echo XDG_CONFIG_DIR=/usr/local/etc/xdg:/etc/xdg >> /etc/environment
> >
> > could be the solution, but I believe that can lead to some unexpected
> > behaviour, when the user also has the distro counterpart of said
> > software installed, i.e. when they installed the local version to test
> > it against the distro version. If they then only change PATH to either
> > prefer the local or the distro version, the latter would also pick the
> > config which is only meant for the local one. The distro version might
> > be outdated an contain obsolete settings.
>
> Yes. The same is true for XDG_DATA_HOME (defaulting to ~/.config/myapp):
> if you have myapp version 1 installed from a distro and myapp version 2
> installed locally, ~/.config/myapp affects both.
Good point, *but* I do not expect the local version to also read /etc/...
It should really only read one user config location and the system wide
one in /usr/local/etc/xdg but never its equivalent in /etc. The latter
is for the distro version. This way I only need to put those settings I
want to change on a per-user basis in XDG_CONFIG_HOME and thus reduce
the probability for conflict between version, if I ever need to run the
distro version. That one can have old settings all it wants in /etc,
since they (*should*) get ignored by the version in ${PREFIX}
(/usr/local).
> If that is unacceptable for your design, then either don't exclusively use
> the XDG basedirs for configuration, or use a versioned directory so that
> each major version will find the most appropriate directory (like the
> way GTK 2, 3 and 4 use $XDG_CONFIG_HOME/gtk-2.0, etc. to allow for the
> format and semantics of their configuration to diverge if necessary).
Well, we opted for simply hard coding the location to the sysconfig file
is expected to be in at compile time, i.e.
SYSSCONFFILE=${PREFIX}/etc/xdg//rc
and a CPP directive which gets set at compile time.
This was the only sane way to get actually predictable behaviour. The
main devs of the project in question seemed rather surprised when I told
them that their app did not do as they thought on my box, since I do
have the distro version installed and they mistakenly put their
sysconfig in the wrong place and the distro version kicked in, when in
fact it should have found nothing, since I still very much expect /etc
to be off limits for anything /usr/local, except for getting information
about the environment, which I still think it should get by other means
than snooping in and *parsing* files in /etc/xdg.
> It is OK to read other locations like /etc/myapp, /usr/local/etc/myapp,
> /usr/share/myapp or /usr/local/share/myapp before or after XDG_CONFIG_HOME
> and XDG_CONFIG_DIRS - or even in between them, if that's what makes most
> sense.
That directly contradicts the spec, does it not? The order is set by
importance, XDG_*_HOME being the most important one. And why would there
be active *config* information in /usr/{,local/}share? Those are for
"data". Configs belong in etc.
Best,
PW
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Mon, Sep 20, 2021 at 02:09:00PM +, 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/// 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 sentim
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Mon, Sep 20, 2021 at 09:46:22AM -0400, Elsie Hupp wrote: > > Yes, and then there is XDG which expects exactly that, which > > then leads to other hacks to soften the isolation of said > > containers, or the inclusion of files which the go out of > > sync and out of date compared to what is in the real /etc. If > > I need hard sandboxing to stop such behaviour, then there is > > a serious bug in the spec. ;) > > Flatpak generally provides indirect access to system libraries > through “runtimes”, so in order to provide access to, for > example, whatever library you’re working on, the library itself > could be added to the Freedesktop runtime, which would then > provide properly sandboxed access to that library. Be that as it may, one should not have to resort to such rather extreme measures just to get sane behaviour back. And please stop drumming for Flatpak. ;) It does have its application but not for this. I mean, come on, more layers of complexity just for this. Plus all the downsides I do not want to discuss here, since they are out of scope. OFF-TOPIC: > P.S. FYI your email client seems to add hard line breaks to > soft-wrap text Yes, that is very much intentional, those are not "soft-wrap" but real line breaks. You should read up on mailing list netiquette[1] if this is news to you. Yes, there is an RFC for that, and please don't go "fixing" my text. ;) > which renders really strangely on my device. Then your device/client is broken. Line length is usually limited to 72 characters on my end (not accounting for quotes) so text is readable on old-school terminals as well. I have made that 65 for this message, since I just realized that said RFC recommends it. Let me know if that's better and I will make this the new default, but I won't change the automatic line breaks, since that is what is expected on virtually every mailing list of repute. > (And I wasn’t sure about the etiquette for quoted email > history. The simple answer is always: reduce to the max. ;) The history is in the thread and you only quote the relevant parts discarding all the irrelevant stuff. Maybe I should value that more myself. > I don’t know how much of the peculiarity is just down to how > mailman works versus how various email clients work, since some > of these issues other mailing-list platforms handle somewhat > more gracefully.) Nothing to do with the platform but everything with the client. Now, I have stopped nagging people about their line lengths since I had the "pleasure" of using Thunderbird for mailing list conversations, which locally suggests line breaks which in fact are just wrapped lines. Back to good old vim and mutt for me it is. ;) [1] http://www.ietf.org/rfc/rfc1855.txt (There might be newer versions, but that is what a quick search came up with)
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Mon, 20 Sep 2021 at 12:28:43 +, Peter White wrote:
> Why would XDG_CONFIG_DIRS need to contain ${PREFIX}/etc/xdg for that?
> The app pretty much already knows where it is supposed to find *its own*
> system-wide config. The location of which *should* be in
> ${PREFIX}/etc/xdg//, yes, but one does not need to check
> XDG_CONFIG_DIRS for that at runtime.
If you are an app author and you want to look for defaults, or even
configuration, in a ${prefix}-relative path, great. Do that! Nobody is
stopping you from doing that.
However, if you want sysadmins to be able to override the defaults of
your app on a system-wide basis, or if you want users to be able to
override the defaults on a per-user basis, they will likely thank you
for using basedirs at runtime to do that, rather than inventing your
own mechanism that requires them to set extra environment variables or
otherwise learn how your app is different.
More concretely, this would be a perfectly reasonable search path to have,
if you want it;
- $XDG_CONFIG_HOME/myapp/myapprc at runtime
(per-user overrides, "most important")
- $dir/myapp/myapprc for each $dir in $XDG_CONFIG_DIRS at runtime
(user and/or sysadmin overrides)
- ${sysconfdir}/myapp/myapprc for compile-time ${sysconfdir}
(installation-specific configuration)
- ${datadir}/myapp/myapprc for compile-time ${datadir}
(fallback/defaults, "least important")
(Vulkan-Loader does something similar to this; dbus also does something
similar to this, but with the data "stack" instead of the config "stack".)
If you did something like that, it would work equally well for
--prefix=/usr/local and --prefix=/opt, and still allow users and sysadmins
to override the settings for myapp the same way they're familiar with for
other apps.
> It would make sense, though, to query XDG_CONFIG_DIRS at *compile time*
I don't think that makes sense. The point of environment variables is that
they are runtime-variable.
> And the more I think about it *and* seeing that no-one seems to ever set
> XDG_CONFIG_DIRS, which then defaults to /etc/xdg, this variable could
> just as well be renamed to the singular version XDG_CONFIG_DIR and only
> contain *one* value
No, that would be an incompatible change that would break pre-existing,
working configurations.
> There is only one XDG_CONFIG_HOME as well.
XDG_CONFIG_HOME has a dual role: it's the highest-precedence configuration
directory, and it's the place that automated per-user configuration-saving
saves modified configuration.
It's entirely valid for a user to do something like this:
XDG_CONFIG_HOME=$HOME/.config
XDG_CONFIG_DIRS=$HOME/dotfiles/xdg:/etc/xdg
with $HOME/.config as the path that is modified automatically when apps
save their configuration, and $HOME/dotfiles/xdg for configuration that
the user edits with a text-editor (perhaps stored in a version control
system).
smcv
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Thu, 16 Sep 2021 at 04:44:17 +, Peter White wrote:
> I am having a hard time finding documentation about the best way to make
> locally installed software recognize its config dir in
> /usr/local/etc/xdg.
One high-level approach to this is: give it sensible defaults, so that it
will work correctly with an empty /etc, and don't install anything to
${sysconfdir}/etc/xdg from the package's build system.
(Those defaults can be in a file in ${datadir} with the same syntax as the
configuration file and a comment that says "do not modify, copy to /etc/xdg
and modify the copy instead", if you want - that's a common approach.)
> One might also think:
>
> # echo XDG_CONFIG_DIR=/usr/local/etc/xdg:/etc/xdg >> /etc/environment
>
> could be the solution, but I believe that can lead to some unexpected
> behaviour, when the user also has the distro counterpart of said
> software installed, i.e. when they installed the local version to test
> it against the distro version. If they then only change PATH to either
> prefer the local or the distro version, the latter would also pick the
> config which is only meant for the local one. The distro version might
> be outdated an contain obsolete settings.
Yes. The same is true for XDG_DATA_HOME (defaulting to ~/.config/myapp):
if you have myapp version 1 installed from a distro and myapp version 2
installed locally, ~/.config/myapp affects both.
If that is unacceptable for your design, then either don't exclusively use
the XDG basedirs for configuration, or use a versioned directory so that
each major version will find the most appropriate directory (like the
way GTK 2, 3 and 4 use $XDG_CONFIG_HOME/gtk-2.0, etc. to allow for the
format and semantics of their configuration to diverge if necessary).
It is OK to read other locations like /etc/myapp, /usr/local/etc/myapp,
/usr/share/myapp or /usr/local/share/myapp before or after XDG_CONFIG_HOME
and XDG_CONFIG_DIRS - or even in between them, if that's what makes most
sense.
smcv
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
> Yes, and then there is XDG which expects exactly that, which then leads to > other hacks to soften the isolation of said containers, or the inclusion of > files which the go out of sync and out of date compared to what is in the > real /etc. If I need hard sandboxing to stop such behaviour, then there is a > serious bug in the spec. ;) Flatpak generally provides indirect access to system libraries through “runtimes”, so in order to provide access to, for example, whatever library you’re working on, the library itself could be added to the Freedesktop runtime, which would then provide properly sandboxed access to that library. Filesystem access within $HOME is generally provided through “portals” on Flatpak though I don’t really understand how those work, yet. — P.S. FYI your email client seems to add hard line breaks to soft-wrap text, which renders really strangely on my device. (And I wasn’t sure about the etiquette for quoted email history. I don’t know how much of the peculiarity is just down to how mailman works versus how various email clients work, since some of these issues other mailing-list platforms handle somewhat more gracefully.)
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Mon, Sep 20, 2021 at 08:50:45AM -0400, Elsie Hupp wrote: > > The way you describe it, it would be OK for any app to just parse the > > config of any other. That just feels wrong, because app A should have no > > business snooping in /etc/xdg/B/Brc. If app B wants to make such > > information available to others it should export it instead of requiring > > those to parse the file. > > To be fair, this is one of the motivations behind Flatpak and Snap. If you > don’t want one app snooping where it shouldn’t, then you make it technically > unable to do so. Yes, and then there is XDG which expects exactly that, which then leads to other hacks to soften the isolation of said containers, or the inclusion of files which the go out of sync and out of date compared to what is in the real /etc. If I need hard sandboxing to stop such behaviour, then there is a serious bug in the spec. ;) Best, PW P.S.: Please do not attach the whole history.
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
> The way you describe it, it would be OK for any app to just parse the config
> of any other. That just feels wrong, because app A should have no business
> snooping in /etc/xdg/B/Brc. If app B wants to make such information available
> to others it should export it instead of requiring those to parse the file.
To be fair, this is one of the motivations behind Flatpak and Snap. If you
don’t want one app snooping where it shouldn’t, then you make it technically
unable to do so.
> On Sep 20, 2021, at 8:28 AM, Peter White wrote:
>
> On Mon, Sep 20, 2021 at 10:20:05AM +0200, David Faure wrote:
>> On dimanche 19 septembre 2021 16:57:22 CEST Peter White wrote:
>>> On Sun, Sep 19, 2021 at 12:19:33PM +0200, David Faure wrote:
On jeudi 16 septembre 2021 18:48:41 CEST Peter White wrote:
> But, /etc should be off limits for software in /usr/local, right?
I don't think this assessment is correct.
For instance, I certainly expect KDE software installed in any prefix, to
respect the global settings in /etc/xdg/kdeglobals
>>>
>>> Why would software need to read that file?
>>
>> Well, that's the point of config files, to be read by software, isn't it?
>
> Well, duh, but not by *other* software. Why would any software have to
> read files it otherwise has no business with? kdeglobals is a file
> related directly to KDE. Plus, every app then also needs to *parse* that
> file. That sounds like an invitation for a whole lot of duplicated
> effort when, if those values are intended to be used, they should be
> available by other means, i.e. provide a library that abstracts that
> away.
>
> The way you describe it, it would be OK for any app to just parse the
> config of any other. That just feels wrong, because app A should have no
> business snooping in /etc/xdg/B/Brc. If app B wants to make such
> information available to others it should export it instead of requiring
> those to
> parse the file.
>
>>> Granted, I know virtually
>>> noting about KDE, but shouldn't there be a facility that makes those
>>> values available by other means, i.e. environment variables, or
>>> a settings daemon or whatever?
>>
>> You want one environment variable per setting in that file? That doesn't
>> scale. A settings daemon might be what gnome does, it doesn't mean that all
>> other free desktops want to have such an architecture. Surely reading files
>> is
>> still allowed in 2021?
>
> Yes, it very much is, just not files of other applications. You seem to
> taking an "illegal" shortcut here, by expecting apps to do things that
> are otherwise frowned upon.
>
>>> And BTW, shouldn't that be /usr/{,local/}share/kdeglobals [1]?
>>
>> No, config files don't go to XDG_DATA_DIRS.
>>
>>> > share/config/ ... A special case is "kdeglobals": this file is
>>> >
>>> > read by all KDE applications.
>>>
>>> and then XDG_DATA_DIRS is the relevant env var which already has the
>>> correct default, as you point out below. Now, I don't know why "config"
>>> files would go anywhere other than ${PREFIX}/etc but that is apparently
>>> what KDE deems the right place.
>>
>> The above documentation is really outdated, it says "kde 3" in many places,
>> it predates the XDG base dir spec (at least, its use by KDE).
>
> Then provide a better reference? That's what my search came up with. ;)
>
>>> Anyhow, if one really needs to make /etc/xdg/kdeglobals available to
>>> apps in /usr/local, then that is one special case that applies to KDE
>>> only
>>
>> I don't believe so. As I said, everyone agrees that /usr is available to
>> apps
>> in /usr/local (since that's the default value for XDG_DATA_DIRS)
>> so why not do the same with config dirs?
>
> And again, *you* talk about /usr and *I* talk about /etc. Compare that
> to PATH. There is no equivalent for /etc, because there doesn't need to
> be.
>
>>> and that is the only case I can think of right now.
>>
>> There are lots of other files in /etc/xdg...
>> For instance /etc/xdg/user-dirs.conf which is not KDE specific at all.
>
> And that also has nothing to do with the config of the app itself. It
> provides information about the environment.
>
XDG_CONFIG_DIRS was modeled very much after XDG_DATA_DIRS,
where I would have tons of other examples like: apps in /usr/local or
anywhere else should still see /usr/share, for e.g. /usr/share/mime which
has the mimetype definitions.
>>>
>>> That is not the same as /etc. The well known behaviour, prior to XDG,
>>> should not be broken for desktops and, as pointed out above, use the
>>> share/.. hierarchy then or whatever, since this seems very much like a
>>> KDE quirk to me and should not be baked into a standard that is supposed
>>> to agnostic of the environment.
>>
>> Please stop saying this is a KDE quirk. It's the XDG base spec that defines
>> /etc/xdg to be the default location for systemwide config files,
>
> And I welcome that effort very much
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Mon, Sep 20, 2021 at 10:20:05AM +0200, David Faure wrote:
> On dimanche 19 septembre 2021 16:57:22 CEST Peter White wrote:
> > On Sun, Sep 19, 2021 at 12:19:33PM +0200, David Faure wrote:
> > > On jeudi 16 septembre 2021 18:48:41 CEST Peter White wrote:
> > > > But, /etc should be off limits for software in /usr/local, right?
> > >
> > > I don't think this assessment is correct.
> > >
> > > For instance, I certainly expect KDE software installed in any prefix, to
> > > respect the global settings in /etc/xdg/kdeglobals
> >
> > Why would software need to read that file?
>
> Well, that's the point of config files, to be read by software, isn't it?
Well, duh, but not by *other* software. Why would any software have to
read files it otherwise has no business with? kdeglobals is a file
related directly to KDE. Plus, every app then also needs to *parse* that
file. That sounds like an invitation for a whole lot of duplicated
effort when, if those values are intended to be used, they should be
available by other means, i.e. provide a library that abstracts that
away.
The way you describe it, it would be OK for any app to just parse the
config of any other. That just feels wrong, because app A should have no
business snooping in /etc/xdg/B/Brc. If app B wants to make such
information available to others it should export it instead of requiring those
to
parse the file.
> > Granted, I know virtually
> > noting about KDE, but shouldn't there be a facility that makes those
> > values available by other means, i.e. environment variables, or
> > a settings daemon or whatever?
>
> You want one environment variable per setting in that file? That doesn't
> scale. A settings daemon might be what gnome does, it doesn't mean that all
> other free desktops want to have such an architecture. Surely reading files
> is
> still allowed in 2021?
Yes, it very much is, just not files of other applications. You seem to
taking an "illegal" shortcut here, by expecting apps to do things that
are otherwise frowned upon.
> > And BTW, shouldn't that be /usr/{,local/}share/kdeglobals [1]?
>
> No, config files don't go to XDG_DATA_DIRS.
>
> > > share/config/ ... A special case is "kdeglobals": this file is
> > >
> > > read by all KDE applications.
> >
> > and then XDG_DATA_DIRS is the relevant env var which already has the
> > correct default, as you point out below. Now, I don't know why "config"
> > files would go anywhere other than ${PREFIX}/etc but that is apparently
> > what KDE deems the right place.
>
> The above documentation is really outdated, it says "kde 3" in many places,
> it predates the XDG base dir spec (at least, its use by KDE).
Then provide a better reference? That's what my search came up with. ;)
> > Anyhow, if one really needs to make /etc/xdg/kdeglobals available to
> > apps in /usr/local, then that is one special case that applies to KDE
> > only
>
> I don't believe so. As I said, everyone agrees that /usr is available to apps
> in /usr/local (since that's the default value for XDG_DATA_DIRS)
> so why not do the same with config dirs?
And again, *you* talk about /usr and *I* talk about /etc. Compare that
to PATH. There is no equivalent for /etc, because there doesn't need to
be.
> > and that is the only case I can think of right now.
>
> There are lots of other files in /etc/xdg...
> For instance /etc/xdg/user-dirs.conf which is not KDE specific at all.
And that also has nothing to do with the config of the app itself. It
provides information about the environment.
> > > XDG_CONFIG_DIRS was modeled very much after XDG_DATA_DIRS,
> > > where I would have tons of other examples like: apps in /usr/local or
> > > anywhere else should still see /usr/share, for e.g. /usr/share/mime which
> > > has the mimetype definitions.
> >
> > That is not the same as /etc. The well known behaviour, prior to XDG,
> > should not be broken for desktops and, as pointed out above, use the
> > share/.. hierarchy then or whatever, since this seems very much like a
> > KDE quirk to me and should not be baked into a standard that is supposed
> > to agnostic of the environment.
>
> Please stop saying this is a KDE quirk. It's the XDG base spec that defines
> /etc/xdg to be the default location for systemwide config files,
And I welcome that effort very much to reduce clutter in /etc. BTW, KDE
should then also put kdeglobals in its own sub/base directory, i.e.
/etc/xdg/kde/kdeglobals. That would make it more consistent with how
XDG_CONFIG_HOME works, which XDG_CONFIG_DIRS is supposed to mirror
system-wide.
> > > And yes, the intent is definitely that they should be read at runtime,
> >
> > Yes, to find some global settings, maybe, but to find its *own* rc-file?
>
> An app's own configuration is combination of the system wide defaults
> (in /etc/xdg), its own installed defaults (in $PREFIX/etc/xdg),
Now we are getting somewhere...
> and the user's
> preferences (in $XDG_CONF
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On dimanche 19 septembre 2021 16:57:22 CEST Peter White wrote:
> On Sun, Sep 19, 2021 at 12:19:33PM +0200, David Faure wrote:
> > On jeudi 16 septembre 2021 18:48:41 CEST Peter White wrote:
> > > But, /etc should be off limits for software in /usr/local, right?
> >
> > I don't think this assessment is correct.
> >
> > For instance, I certainly expect KDE software installed in any prefix, to
> > respect the global settings in /etc/xdg/kdeglobals
>
> Why would software need to read that file?
Well, that's the point of config files, to be read by software, isn't it?
> Granted, I know virtually
> noting about KDE, but shouldn't there be a facility that makes those
> values available by other means, i.e. environment variables, or
> a settings daemon or whatever?
You want one environment variable per setting in that file? That doesn't
scale. A settings daemon might be what gnome does, it doesn't mean that all
other free desktops want to have such an architecture. Surely reading files is
still allowed in 2021?
> And BTW, shouldn't that be /usr/{,local/}share/kdeglobals [1]?
No, config files don't go to XDG_DATA_DIRS.
> > share/config/ ... A special case is "kdeglobals": this file is
> >
> > read by all KDE applications.
>
> and then XDG_DATA_DIRS is the relevant env var which already has the
> correct default, as you point out below. Now, I don't know why "config"
> files would go anywhere other than ${PREFIX}/etc but that is apparently
> what KDE deems the right place.
The above documentation is really outdated, it says "kde 3" in many places,
it predates the XDG base dir spec (at least, its use by KDE).
> Anyhow, if one really needs to make /etc/xdg/kdeglobals available to
> apps in /usr/local, then that is one special case that applies to KDE
> only
I don't believe so. As I said, everyone agrees that /usr is available to apps
in /usr/local (since that's the default value for XDG_DATA_DIRS)
so why not do the same with config dirs?
> and that is the only case I can think of right now.
There are lots of other files in /etc/xdg...
For instance /etc/xdg/user-dirs.conf which is not KDE specific at all.
> > XDG_CONFIG_DIRS was modeled very much after XDG_DATA_DIRS,
> > where I would have tons of other examples like: apps in /usr/local or
> > anywhere else should still see /usr/share, for e.g. /usr/share/mime which
> > has the mimetype definitions.
>
> That is not the same as /etc. The well known behaviour, prior to XDG,
> should not be broken for desktops and, as pointed out above, use the
> share/.. hierarchy then or whatever, since this seems very much like a
> KDE quirk to me and should not be baked into a standard that is supposed
> to agnostic of the environment.
Please stop saying this is a KDE quirk. It's the XDG base spec that defines
/etc/xdg to be the default location for systemwide config files,
while KDE was using historically share/config as you found out.
> > And yes, the intent is definitely that they should be read at runtime,
>
> Yes, to find some global settings, maybe, but to find its *own* rc-file?
An app's own configuration is combination of the system wide defaults
(in /etc/xdg), its own installed defaults (in $PREFIX/etc/xdg), and the user's
preferences (in $XDG_CONFIG_HOME). This assumes the XDG_CONFIG_DIRS is
set to contain the first two values, as is customary when using a custom
prefix since the exact same thing has to be done with XDG_DATA_DIRS.
The only case where one doesn't have to add $PREFIX to XDG_DATA_DIRS
is the case where $PREFIX is /usr/local/, which is why I'm suggesting doing
the same with XDG_CONFIG_DIRS by adding /usr/local/etc/xdg as a default value.
> > so that [advanced] users can install things in custom prefixes and make
> > things work by setting a few env vars.
>
> That is not something for "advanced" users, /usr/local is *the* very
> well known default for make.
I know, that's what I'm saying.
By custom I mean really custom (e.g. /opt or $HOME/install or whatever).
> And the expectation is that everything
> needed to run software installed by 'make install' is available *inside*
> said prefix.
Agreed. Hence /usr/local/etc/xdg.
> Just look at the default PATH on any distro. It will contain
> /usr/local/bin and that will take precedence over /usr/bin. So one does
> not need to be "advanced" to run 'make && sudo make install' and then
> just run the locally built software by entering its binary's name
> without any further ado.
Agreed, hence my suggestion.
> > What it seems to me, is that /usr/local/etc/xdg should simply be added to
> > the default value for XDG_CONFIG_DIRS.
>
> Again, that breaks prior art.
Bugfixing is about changing behaviour indeed, but for the better.
> Picture this: Software "foobar" installed in /usr/local finds *file*
> foobarrc in /usr/local/etc/xdg/foobar with *information*/setting A but
> not B in there, it will go on and read /etc/xdg/foobar/foobarrc and use
> s
