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
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.", a
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
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
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
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
>
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
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? 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? And BTW, shouldn't that be
/usr/{,local/}share/kdeglobals [1]?
> 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.
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, and that is the only case I can think of right now. One can just
make that work like so:
# ln -s /etc/xdg/kdeglobals ${PREFIX}/etc/xdg/kdeglobals
> 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.
> 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?
> 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. And the expectation is that everything
needed to run software installed by 'make install' is available *inside*
said prefix. Anything *else* is for advanced users that can just make it
work by providing the proper symlink(s), for instance.
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.
> 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. As was pointed out in this thread before,
the spec talks about "information" as opposed to files.
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
setting B from there, if a distro provided version is also installed.
In turn, running the distro version would also prefer setting A in
/usr/local/etc/xdg/foobar/foobarrc despite there being A with a
*different* value in /etc/xdg/foobar/foobarrc. Setting A in the most
certainly made for a newer version of foobarrc in /usr/local could just
as well lead to a DoS of the distro version of foobar, because at the
time it was packaged the newer, now legal, value of A was illegal.
And, since setting B was deprecated in the meantime the local version
will also deny service.
How is that for a worst case? ;)
> It's inconsistent that XDG_DATA_DIRS
> defaults to /usr/local/share:/usr/share while XDG_CONFIG_DIRS defaults to
> only
> /etc/xdg instead of /usr/local/etc/xdg:/etc/xdg
And there might be good reasons for that, as just outlined above, which
is why I would very much like some input from the original authors on
this topic.
The main question still remains without a clear answer: Who or what
should query XDG_CONFIG_DIRS and to what end? Regular software: should
it really use it to find and then read its very own config file(s), the
location of which being known at compile time anyways? Or is this for
getting *other* information about the environment which said software
has no other means of getting, like kdeglobals, for instance?
[1] https://userbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
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 That file has things like default fonts which should apply to all KDE applications, they should apply whatever the install prefix is, for a more consistent user experience. 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. And yes, the intent is definitely that they should be read at runtime, so that [advanced] users can install things in custom prefixes and make things work by setting a few env vars. What it seems to me, is that /usr/local/etc/xdg should simply be added to the default value for XDG_CONFIG_DIRS. It's inconsistent that XDG_DATA_DIRS defaults to /usr/local/share:/usr/share while XDG_CONFIG_DIRS defaults to only /etc/xdg instead of /usr/local/etc/xdg:/etc/xdg -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
RE: XDG_CONFIG_DIRS an /usr/local/etc/xdg
Dear Peter, What XDG Base Directory does not particularly contemplate is that there might be a collision between the config or data file names relied upon by different applications (including different versions of the same application). Again, this has nothing in particular to do with how applications are packaged or delivered, or with where or how they are installed. The issue could as easily affect multiple vendor-supplied packages or multiple from-source installations to /usr/local the same way it does mixes of those. It could affect pairs of altogether distinct applications, too. You may consider this a flaw in the spec if you prefer, but I just consider the scenario to be outside Base Directory's scope. It is not a problem that BD intends to address. To the extent that it sometimes has particular impact on the concurrent installation of multiple versions of the same application, I think it more appropriate to attribute that to the application involved. One thing that some Linux distributions do when they provide concurrently-installable packages of different versions of the same software is to configure or patch one or more of them to include a version number in their config file names. This resolves the name collision, allowing each version to find the correct config and data files, and it is in no way specific to software packages or installation location. And of course there are ways to accommodate multiple installations that do not require patching or special configuration. The list in my first response covered some of these. Inasmuch as supporting multiple concurrent installations is rarely a characteristic to which software developers attribute much importance, you should not be surprised if it takes extra work on the install side to accommodate that. Regards, John -Original Message- From: xdg On Behalf Of Peter White Sent: Thursday, September 16, 2021 11:49 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 Thu, Sep 16, 2021 at 04:15:07PM +, Bollinger, John C wrote: > The value of XDG_CONFIG_DIRS, if set, is expected to be a string > designating one or more directories to search for config files, in > priority order. If multiple directories are specified then they are > separated by colon characters (:). This represents a search path, > similar to the executable search path conveyed via $PATH. > > HOWEVER, Base Directory does not specify a first match wins rule. It > attributes more importance (the spec's terminology) to files located > in earlier directories in the list, but that does not imply that only > one can be used. Fair point, I was talking about "information" as opposed to files. Then the first match wins is exactly the same as your description. ;) But, /etc should be off limits for software in /usr/local, right? So XDG_CONFIG_DIRS has a hole in the spec, because one cannot set it up so that distro software _and_ software in /usr/local do the right thing, because whatever is set as "more important" wins for both. Or, as I said, maybe it should not be used like this to begin with? But then, what is its *intended* use? > At least a limited ability to merge multiple configs is suggested by > the provision for XDG_CONFIG_HOME, which designates a user-specific > search directory of even higher importance that, alone among all > these, is assumed to be writable by the user. This latter is where a > user would record their personal config customizations, and a > user-friendly application with many configuration options will not > insist that users provide a complete configuration just to customize a > few items. That is a very good point. The software in question currently does the latter, but I think this is out of scope for my initial question. I can live with a first match wins rule on file basis, for the time being. Best, PW Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer
RE: XDG_CONFIG_DIRS an /usr/local/etc/xdg
The value of XDG_CONFIG_DIRS, if set, is expected to be a string designating one or more directories to search for config files, in priority order. If multiple directories are specified then they are separated by colon characters (:). This represents a search path, similar to the executable search path conveyed via $PATH. HOWEVER, Base Directory does not specify a first match wins rule. It attributes more importance (the spec's terminology) to files located in earlier directories in the list, but that does not imply that only one can be used. A viable alternative is for applications to look for their config files in all the specified directories, and to merge the contents according to priority when more than one is found. At least a limited ability to merge multiple configs is suggested by the provision for XDG_CONFIG_HOME, which designates a user-specific search directory of even higher importance that, alone among all these, is assumed to be writable by the user. This latter is where a user would record their personal config customizations, and a user-friendly application with many configuration options will not insist that users provide a complete configuration just to customize a few items. Regards, John -Original Message- From: xdg On Behalf Of Elsie Hupp Sent: Thursday, September 16, 2021 10:40 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. > XDG_CONFIG_DIRS acts like PATH does: first match wins, which I would > not expect to happen with conffiles. In general I believe the expectation is for the XDG variables with the plural suffix (i.e. ending in "S") to return array values. String arrays in C are weird, but it's possible that you have the option of checking each item in the array rather than just using the first one. I just checked the GLib documentation, and g_get_system_config_dirs(), and it says: > Returns an ordered list of base directories in which to access system-wide > configuration information. > > ... > > > Returns: An array of filename > > a `NULL`-terminated array of strings owned by GLib that must not be > modified or freed. https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.gtk.org%2Fglib%2Ffunc.get_system_config_dirs.htmldata=04%7C01%7CJohn.Bollinger%40stjude.org%7C44e7e297444d479661a508d979297044%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C637674042331996338%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=v5PpWlMn1cERhkW2aCOomNXbfdR2wMxh%2BhXfc73zeEo%3Dreserved=0 So how to access subsequent array entries would probably depend on if or whether you're using one of GObject's other language bindings. Looking at Qt's implementation, by comparison, they have these values that look relevant: > ConfigLocation"~/.config", "/etc/xdg" > GenericConfigLocation "~/.config", "/etc/xdg" > AppConfigLocation "~/.config/", "/etc/xdg/" https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.qt.io%2Fqt-5%2Fqstandardpaths.htmldata=04%7C01%7CJohn.Bollinger%40stjude.org%7C44e7e297444d479661a508d979297044%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C637674042331996338%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=YpY9Gx5v4Uh9rm2V4bMEJ3dJn8Sz1CZLn9vOWxd0PAQ%3Dreserved=0 I don't remember exactly how GLib implements this, but it probably returns the same values as QStandardPaths, albeit possibly in a different order. Basically if you have a preferred config directory (or an ordered list of preferred directories), you could check each directory on your own list against the directories returned by g_get_system_config_dirs(), or other define an algorithm creating an alternatively sorted array from the g_get_system_config_dirs() return values. It sounds like what you would want to do here is prefer any array value outside the user's home directory and only use an array value inside the user's home directory as a fallback. > I think that's why: you cannot write inside such a container, so > system- wide configs cannot be changed. XDG_CONFIG_HOME has the > problem, that one cannot provide a default for everyone, which is the > purpose of a system-wide config and it cannot be installed by make > install, unless each user installs the software to $HOME/.local. Now, > that can't be right. ;) If you're specifically trying to work within Flatpak, the Flathub Discourse might also be a good place to ask: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.flathub.org%2Fdata=04%7C01%7CJohn.Bollinger%40stjude.org%7C44e7e297444d479661a508d979297044%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C637674042331996338%7CUnknown%7CTWFpbGZ
RE: XDG_CONFIG_DIRS an /usr/local/etc/xdg
Dear Peter, XDG Base Directory specifies the significance of certain environment variables. How those obtain their values is out of the specification's scope. It varies with execution environment and with execution context. Some of the tools at your disposal on various systems are: - The /etc/environment (since you mentioned it). This is little used in my experience, fairly inflexible, and applicable only to certain execution environments and contexts - System-wide shell configuration scripts. Different shells have different ones. For Bash, for example, these would be /etc/profile and /etc/bashrc - Some environments (RedHat- and Debian-family Linuxes, for example) augment this with a drop-in system revolving around files in /etc/profile.d/ - These have access to the full language of the corresponding shell, and thus have a lot of flexibility - Per-user shell configuration scripts (~/.bash_profile and ~/.bashrc for Bash, for example) - These, too, have the flexibility offered by the corresponding shell language - They are also user-specific, which is important on multi-user systems - But of course, each user needs to manage their own - Scripts that launch new shells with special environment configurations - The environment modules system - Wrapper scripts around selected binaries, to launch them with modified or augmented environment - These are application-specific instead of user-specific > So I guess, my first question is, if XDG_CONFIG_DIRS is even meant to be used > by locally installed software, its default seems to suggest otherwise? Or is > this maybe just an oversight in the spec? The Base Directory spec is agnostic to the source and manner of installation of software that makes use of it. You can use any of a variety of mechanisms to ensure that the wanted config directories are specified therein. In any case, you generally do not have a choice in whether a particular third-party application uses Base Directory to locate its files. I see no particular oversight in the spec in this regard. Your concerns seem to be focused mostly on how to deal with having multiple versions of the same application installed simultaneously. The challenges involved in making that work for applications that rely on XDG Base Directory are not tied to installation manner or location. You should first consider whether you really want to have multiple versions at all. If you are sure you do, then you should furthermore distinguish between the case where you just want to test a different version and the case where you want to maintain multiple versions in parallel indefinitely. I would approach the two differently, and in particular, I would arrange for better isolation in the test-only case than you seem to be describing. > I have pondered this for a while now and could also not find anything via > search engine or on this list, so I figured I actually ask the ones who wrote > the spec. I did not write the spec, but I have implemented it. I'm uncertain whether those who did write it hang around here. Anyway, your questions seem to fall more in the general system administration area than in the area of the spec itself. Regards, John Bollinger -Original Message- From: xdg On Behalf Of Peter White Sent: Wednesday, September 15, 2021 11:44 PM To: xdg@lists.freedesktop.org Subject: XDG_CONFIG_DIRS an /usr/local/etc/xdg Caution: External Sender. Do not open unless you know the content is safe. Dear list, 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. Of course, the quick and easy answer could be: $ env XDG_CONFIG_DIRS=/usr/local/etc/xdg foobar But that is not something one can ask their users if they install software from an upstream repository. I believe XDG_CONFIG_DIRS is unset on most systems and thus defaults to /etc/xdg, i.e. returned by g_get_system_config_dirs(), so most people would have to set it manually to make software in /usr/local pick up its config from there, which it should IMO. 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. >From what other software (i.e. a shell) does, I believe the correct way would >be to use the /usr/local/etc/xdg when running a local version and /etc/xdg >when running the distro version, if I am not mistaken. So I guess, my first question is, if XDG_CONFIG_DIRS is even
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Thu, Sep 16, 2021 at 01:47:51PM -0400, Elsie Hupp wrote: > >>> I was hoping they would be, or is there a better way of contacting them? > >> > >> The authors all have individual email addresses at the top of the > >> specification: > > > > I did notice that, but why ask them privately? Mailing lists are there > > so a question can be answered *once*, and the record stays online for > > others to find. I did my due diligence before asking here by searching > > the archive. But I seem to be first one to ask. From now on others can > > at least find that it has been asked and maybe won't have to bother the > > authors again. > > Yes, indeed, asking here first is probably the best approach. The > individual email addresses are just useful if you don’t hear back from > any of the authors otherwise, and you really want their perspectives. Precisely. > Presuming they’re all on this mailing list, a fallback approach might > be to send them a direct email (individually or in a group) nagging > them to respond to this thread. Oh, I will, if this cannot be resolved here. ;) > (Of course, it isn’t fun to feel like a nag…) Which is why I am holding off on that approach for the time being. They are busy people and should be given time. I consider your suggestion a matter of last resort. We are not there yet. ;)
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
Dear John,
would you please reply on the list, it being the only recipient? By
putting me first, I don't get the list headers cannot do a proper list
reply.
On Thu, Sep 16, 2021 at 05:38:37PM +, Bollinger, John C wrote:
> Dear Peter,
>
> What XDG Base Directory does not particularly contemplate is that
> there might be a collision between the config or data file names
> relied upon by different applications (including different versions of
> the same application). Again, this has nothing in particular to do
> with how applications are packaged or delivered, or with where or how
> they are installed. The issue could as easily affect multiple
> vendor-supplied packages or multiple from-source installations to
> /usr/local the same way it does mixes of those. It could affect pairs
> of altogether distinct applications, too.
And that should not be an issue. This feels like a huge regression to
the tried and tested way I described. Have a look at the Filesystem
Hierarchy Standard which predates XDG by a huge margin. All the
admin/user *should* have to do is making sure that they run the
appropriate binary by either manipulating path or running by specifying
the absolute path to the binary explicitly.
> You may consider this a flaw in the spec if you prefer, but I just
> consider the scenario to be outside Base Directory's scope.
Yes, and that would make it an oversight, as I suggested in my initial
message. ;) Because, how do you make use of facilities like, i.e.
g_get_system_config_dirs() in a program in a portable way if the
simplest of all installation methods (make install) is not accounted
for?
> It is not
> a problem that BD intends to address. To the extent that it sometimes
> has particular impact on the concurrent installation of multiple
> versions of the same application, I think it more appropriate to
> attribute that to the application involved.
Well, again, that rules out *any* use of XDG_CONFIG_DIRS or the helper
functions querying it at *runtime*, because one must check at compile
time anyway and if that is the case one can just as well not use it at
all. Maybe it is useful to check at compile time if the target distro
prefers other locations and just prepend PREFIX to that, so
${PREFIX}/etc is consistent with what the distro does in /etc.
> One thing that some Linux distributions do when they provide
> concurrently-installable packages of different versions of the same
> software is to configure or patch one or more of them to include a
> version number in their config file names.
I am not talking about multiple versions in the same PREFIX. I am
talking about the tried and tested way of having one version in /usr and
/usr/local each.
Best,
PW
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Thursday, September 16, 2021 12:51:05 PM Peter White wrote: > P.S.: Please reply to the list, so the headers stay intact. I almost did > not notice and would have replied to you privately. Also, please don't > break my formatting. I am trying to obey the netiquette of limiting line > length and quite frankly, so should you. ;) +1 (especialy on keeping the conversation on list)
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
>>> I was hoping they would be, or is there a better way of contacting them? >> >> The authors all have individual email addresses at the top of the >> specification: > > I did notice that, but why ask them privately? Mailing lists are there > so a question can be answered *once*, and the record stays online for > others to find. I did my due diligence before asking here by searching > the archive. But I seem to be first one to ask. From now on others can > at least find that it has been asked and maybe won't have to bother the > authors again. Yes, indeed, asking here first is probably the best approach. The individual email addresses are just useful if you don’t hear back from any of the authors otherwise, and you really want their perspectives. Presuming they’re all on this mailing list, a fallback approach might be to send them a direct email (individually or in a group) nagging them to respond to this thread. (Of course, it isn’t fun to feel like a nag…) I should probably switch my own subscription here to digest mode.
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Thu, Sep 16, 2021 at 01:21:15PM -0400, Elsie Hupp wrote: > >>> I have pondered this for a while now and could also not find > >>> anything via search engine or on this list, so I figured I actually > >>> ask the ones who wrote the spec. > >> > >> I did not write the spec, but I have implemented it. I'm uncertain > >> whether those who did write it hang around here. > > > > I was hoping they would be, or is there a better way of contacting them? > > The authors all have individual email addresses at the top of the > specification: I did notice that, but why ask them privately? Mailing lists are there so a question can be answered *once*, and the record stays online for others to find. I did my due diligence before asking here by searching the archive. But I seem to be first one to ask. From now on others can at least find that it has been asked and maybe won't have to bother the authors again. > >> Anyway, your questions seem to fall more in the general system > >> administration area than in the area of the spec itself. > > > > I respectfully disagree, since it is a question about what should or > > maybe should *not* happen at compile time or at runtime, respectively. I > > am asking for a general way to make the software redistributable but > > still installable locally, like virtually every software project makes > > possible. The admin/user *should* have nothing more to do than making > > sure that PATH is set correctly to have /usr/local take precedence, but > > that is already taken care of in virtually every distro. > > It may be worthwhile to add more guidance about “best practices” to > the text of the specification, even without any changes to the > underlying implementations. That is one outcome I would welcome. I am still not ruling out that my thought process is off by missing what XDG_CONFIG_DIRS is intended to be used for. Currently, I am leaning towards: don't use it at runtime, check it at compile time prepend PREFIX and configure the software to hardcode that value. Best, PW
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
>>> I have pondered this for a while now and could also not find >>> anything via search engine or on this list, so I figured I actually >>> ask the ones who wrote the spec. >> >> I did not write the spec, but I have implemented it. I'm uncertain >> whether those who did write it hang around here. > > I was hoping they would be, or is there a better way of contacting them? The authors all have individual email addresses at the top of the specification: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html Waldo Bastian Allison Karlitskaya Lennart Poettering Johannes Löthberg >> Anyway, your questions seem to fall more in the general system >> administration area than in the area of the spec itself. > > I respectfully disagree, since it is a question about what should or > maybe should *not* happen at compile time or at runtime, respectively. I > am asking for a general way to make the software redistributable but > still installable locally, like virtually every software project makes > possible. The admin/user *should* have nothing more to do than making > sure that PATH is set correctly to have /usr/local take precedence, but > that is already taken care of in virtually every distro. It may be worthwhile to add more guidance about “best practices” to the text of the specification, even without any changes to the underlying implementations.
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Thu, Sep 16, 2021 at 02:49:40PM +, Bollinger, John C wrote: > Your concerns seem to be focused mostly on how to deal with having > multiple versions of the same application installed simultaneously. Exactly. > The challenges involved in making that work for applications that rely > on XDG Base Directory are not tied to installation manner or location. Well, they should be then. ;) It is a pretty common scenario and has been thought of and accounted for in other (non/pre-XDG) software. I try upstream versions on a regular basis, i.e. zsh (really only for testing) or mpv which I run locally installed version of but do have the distro version as fallback, in case there is breakage with a new upstream version. It is as simple as changing PATH and the software the also picks its config from the appropriate sysconf location "automagically". Now, mpv hardcodes the location of its sysconf dir at compile time accounting for PREFIX. Seems like that needs to happen with the project I am thinking of here, which begs the question if there is really any meaningful use for facilities like g_get_sysconfig_dirs(), if one has to decide at compile time anyway. > You should first consider whether you really want to have multiple > versions at all. Yes, very much so, it should always be possible to run a locally installed version which takes precedence. I mean, look at /usr/local (or /opt) in the Filesystem Hierarchy Standard. That is precisely the use case they are there for. All that needs to be done to make that work is configure PATH, which most distros already setup that way, i.e.: PATH=/usr/local/bin:/usr/bin Plus, one cannot always uninstall the distro version without violating dependencies of other packages, so the package manager refuses removal, and rightly so. > If you are sure you do, then you should furthermore > distinguish between the case where you just want to test a different > version and the case where you want to maintain multiple versions in > parallel indefinitely. I should not have to, see above. ;) Why install software to /usr/local if it then goes out of its way to find sysconfig dirs *outside* the PREFIX? The more I think about it the less I am thinking that querying XDG_CONFIG_DIRS is the right thing to do, at runtime that is, because one should expect it to point to the distro's /etc/xdg, where local software has no business. > > I have pondered this for a while now and could also not find > > anything via search engine or on this list, so I figured I actually > > ask the ones who wrote the spec. > > I did not write the spec, but I have implemented it. I'm uncertain > whether those who did write it hang around here. I was hoping they would be, or is there a better way of contacting them? > Anyway, your questions seem to fall more in the general system > administration area than in the area of the spec itself. I respectfully disagree, since it is a question about what should or maybe should *not* happen at compile time or at runtime, respectively. I am asking for a general way to make the software redistributable but still installable locally, like virtually every software project makes possible. The admin/user *should* have nothing more to do than making sure that PATH is set correctly to have /usr/local take precedence, but that is already taken care of in virtually every distro. The way I understand it now, is that XDG_CONFIG_DIRS has its use *only* at compile time for package maintainers, but that makes it a dud, mostly, since that is what SYSCONFDIR can be used for and has been long before the conception of the XDG spec. Best, PW P.S.: Please reply to the list, so the headers stay intact. I almost did not notice and would have replied to you privately. Also, please don't break my formatting. I am trying to obey the netiquette of limiting line length and quite frankly, so should you. ;)
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Thu, Sep 16, 2021 at 04:15:07PM +, Bollinger, John C wrote: > The value of XDG_CONFIG_DIRS, if set, is expected to be a string > designating one or more directories to search for config files, in > priority order. If multiple directories are specified then they are > separated by colon characters (:). This represents a search path, > similar to the executable search path conveyed via $PATH. > > HOWEVER, Base Directory does not specify a first match wins rule. It > attributes more importance (the spec's terminology) to files located > in earlier directories in the list, but that does not imply that only > one can be used. Fair point, I was talking about "information" as opposed to files. Then the first match wins is exactly the same as your description. ;) But, /etc should be off limits for software in /usr/local, right? So XDG_CONFIG_DIRS has a hole in the spec, because one cannot set it up so that distro software _and_ software in /usr/local do the right thing, because whatever is set as "more important" wins for both. Or, as I said, maybe it should not be used like this to begin with? But then, what is its *intended* use? > At least a limited ability to merge multiple configs is suggested by > the provision for XDG_CONFIG_HOME, which designates a user-specific > search directory of even higher importance that, alone among all > these, is assumed to be writable by the user. This latter is where a > user would record their personal config customizations, and a > user-friendly application with many configuration options will not > insist that users provide a complete configuration just to customize a > few items. That is a very good point. The software in question currently does the latter, but I think this is out of scope for my initial question. I can live with a first match wins rule on file basis, for the time being. Best, PW
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
> The value of XDG_CONFIG_DIRS, if set, is expected to be a string designating > one or more directories to search for config files, in priority order. If > multiple directories are specified then they are separated by colon > characters (:). This represents a search path, similar to the executable > search path conveyed via $PATH. I did see that XDG_CONFIG_DIRS returns a single string with colon separators. GLib and Qt just use their own preferred data structures instead (as a convenience). > HOWEVER, Base Directory does not specify a first match wins rule. It > attributes more importance (the spec's terminology) to files located in > earlier directories in the list, but that does not imply that only one can be > used. A viable alternative is for applications to look for their config > files in all the specified directories, and to merge the contents according > to priority when more than one is found. At least a limited ability to merge > multiple configs is suggested by the provision for XDG_CONFIG_HOME, which > designates a user-specific search directory of even higher importance that, > alone among all these, is assumed to be writable by the user. This latter is > where a user would record their personal config customizations, and a > user-friendly application with many configuration options will not insist > that users provide a complete configuration just to customize a few items. Thanks for the best-practice advice!
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Thu, Sep 16, 2021 at 11:39:30AM -0400, Elsie Hupp wrote: > > XDG_CONFIG_DIRS acts like PATH does: first match wins, which > > I would not expect to happen with conffiles. > > In general I believe the expectation is for the XDG variables with the > plural suffix (i.e. ending in “S”) to return array values. String > arrays in C are weird, but it’s possible that you have the option of > checking each item in the array rather than just using the first one. That is not a problem here. The software does the right thing. The question is more like, if it should be querying XDG_CONFIG_DIRS at runtime in the first place. I am more and more suspecting, that it should not, or that there is little to no benefit in doing so and can lead to unintended behaviour. > https://docs.gtk.org/glib/func.get_system_config_dirs.html > > So how to access subsequent array entries would probably depend on if or > whether you’re using one of GObject’s other language bindings. > > Looking at Qt’s implementation, by comparison, they have these values that > look relevant: > > > ConfigLocation "~/.config", "/etc/xdg" > > GenericConfigLocation "~/.config", "/etc/xdg” > > AppConfigLocation "~/.config/", "/etc/xdg/" Yes, XDG_CONFIG_HOME takes precedence, of course. Or what other point am I missing? > Basically if you have a preferred config directory (or an ordered list > of preferred directories), you could check each directory on your own > list against the directories returned by g_get_system_config_dirs(), > or other define an algorithm creating an alternatively sorted array > from the g_get_system_config_dirs() return values. That seems a lot of hassle (at runtime, mind you) for questionable gain. > It sounds like what you would want to do here is prefer any array > value outside the user’s home directory and only use an array value > inside the user’s home directory as a fallback. No, of course *not*, the user's config takes precedence, always. ;) > > I think that's why: you cannot write inside such a container, so system- > > wide configs cannot be changed. XDG_CONFIG_HOME has the problem, that > > one cannot provide a default for everyone, which is the purpose of a > > system-wide config and it cannot be installed by make install, unless > > each user installs the software to $HOME/.local. Now, that can't be > > right. ;) > > If you’re specifically trying to work within Flatpak, the Flathub Discourse > might also be a good place to ask: No, I don't. I am asking a general question. Software installation is as easy as: make && sudo make install But it should not make things harder for people, who do want to package it, like flatpak for instance. Best, Peter
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
> XDG_CONFIG_DIRS acts like PATH does: first match wins, which > I would not expect to happen with conffiles. In general I believe the expectation is for the XDG variables with the plural suffix (i.e. ending in “S”) to return array values. String arrays in C are weird, but it’s possible that you have the option of checking each item in the array rather than just using the first one. I just checked the GLib documentation, and g_get_system_config_dirs(), and it says: > Returns an ordered list of base directories in which to access system-wide > configuration information. > > … > > > Returns: An array of filename > > a `NULL`-terminated array of strings owned by GLib that must not be > modified or freed. https://docs.gtk.org/glib/func.get_system_config_dirs.html So how to access subsequent array entries would probably depend on if or whether you’re using one of GObject’s other language bindings. Looking at Qt’s implementation, by comparison, they have these values that look relevant: > ConfigLocation"~/.config", "/etc/xdg" > GenericConfigLocation "~/.config", "/etc/xdg” > AppConfigLocation "~/.config/", "/etc/xdg/" https://doc.qt.io/qt-5/qstandardpaths.html I don’t remember exactly how GLib implements this, but it probably returns the same values as QStandardPaths, albeit possibly in a different order. Basically if you have a preferred config directory (or an ordered list of preferred directories), you could check each directory on your own list against the directories returned by g_get_system_config_dirs(), or other define an algorithm creating an alternatively sorted array from the g_get_system_config_dirs() return values. It sounds like what you would want to do here is prefer any array value outside the user’s home directory and only use an array value inside the user’s home directory as a fallback. > I think that's why: you cannot write inside such a container, so system- > wide configs cannot be changed. XDG_CONFIG_HOME has the problem, that > one cannot provide a default for everyone, which is the purpose of a > system-wide config and it cannot be installed by make install, unless > each user installs the software to $HOME/.local. Now, that can't be > right. ;) If you’re specifically trying to work within Flatpak, the Flathub Discourse might also be a good place to ask: https://discourse.flathub.org/ Also the Freedesktop Flatpak list: https://lists.freedesktop.org/mailman/listinfo/flatpak I don’t know what the application you’re working on does, but it might also need to be a Flatpak runtime or be packaged within a Flatpak runtime, in which case it might also be worth asking the maintainers of the Freedesktop SDK about it: https://gitlab.com/freedesktop-sdk/freedesktop-sdk (I’ve been on this mailing list for a couple months, and it’s extremely quiet, hence why I’m suggesting other places to reach out.)
Re: XDG_CONFIG_DIRS an /usr/local/etc/xdg
On Thu, Sep 16, 2021 at 01:10:30AM -0400, Elsie Hupp wrote: > I’m by no means an expert on this, but it may be possible that by not > implementing XDG_CONFIG_DIRS the distros’ intention may be for > applications to use, for example, XDG_CONFIG_HOME instead. It may be > worth asking your distro’s maintainers why the variable is unset. The reason might very well be the possibly unexpected behaviour I mentioned. XDG_CONFIG_DIRS acts like PATH does: first match wins, which I would not expect to happen with conffiles. As I said I expect local software to pick its conf from the local prefix and distro provided software to use an empty prefix for /etc, exclusively. > By comparison, looking at the Flatpak documentation, for example, they > don’t even mention XDG_CONFIG_DIRS: > > https://docs.flatpak.org/en/latest/conventions.html?#xdg-base-directories > > …though Flatpak is specifically intended to be sandboxed, so their > environmental variables are set internally, and system-level writable > directories are generally discouraged. I think that's why: you cannot write inside such a container, so system- wide configs cannot be changed. XDG_CONFIG_HOME has the problem, that one cannot provide a default for everyone, which is the purpose of a system-wide config and it cannot be installed by make install, unless each user installs the software to $HOME/.local. Now, that can't be right. ;) > If you need to use /usr/local/etc/xdg instead of /etc/xdg specifically > in order to work with a different, pre-existing application, it may be > worth looking at that application’s code and asking its developers > about it, as well. Which is precisely why I am asking. I am in the process of proposing changes to that project, because it has/had rather peculiar install and runtime routines, i.e. installing outside PREFIX, overwriting distro managed files and using /etc (not even /etc/xdg, let alone /usr/local/etc/xdg), despite them facilitating g_get_system_config_dirs() to find configs, which suggests, they want to comply to the spec, but they won't apply my changes yet, since there is disagreement over where in /usr/local (etc or etc/xdg) the config should go and how to actually find it at runtime. So I am asking here for guidance by the folks who should know best, so I can go back there with authoritative information, hopefully. Something needs to change, might as well do it right. ;) I found XDG_CONFIG_DIRS to be unset on Ubuntu and expect that to be the case for all distributions because of the above mentioned PATH-like behaviour of this facility. So, either we find a way to make it work flexibly with XDG_CONFIG_DIRS or it needs to be set an compile time. I would very much prefer the first option and want to know, if that is possible or even intended. > > On Sep 16, 2021, at 12:44 AM, Peter White wrote: > > > > Dear list, > > > > 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. Of course, the quick and easy answer could be: > > > >$ env XDG_CONFIG_DIRS=/usr/local/etc/xdg foobar > > > > But that is not something one can ask their users if they install > > software from an upstream repository. I believe XDG_CONFIG_DIRS is unset > > on most systems and thus defaults to /etc/xdg, i.e. returned by > > g_get_system_config_dirs(), so most people would have to set it manually > > to make software in /usr/local pick up its config from there, which it > > should IMO. > > > > 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. > > From what other software (i.e. a shell) does, I believe the correct way > > would be to use the /usr/local/etc/xdg when running a local version and > > /etc/xdg when running the distro version, if I am not mistaken. > > > > So I guess, my first question is, if XDG_CONFIG_DIRS is even meant to be > > used by locally installed software, its default seems to suggest > > otherwise? Or is this maybe just an oversight in the spec? I'd find that > > hard to believe, given that it's been around for quite a while now, so > > my thought process may very well be flawed here. > > > > I have pondered this for a while now and could also not find anything > > via search engine or on this list, so I figured I actually ask the ones > > who wrote the spec. ;) > > > > > > Best, > > PW >
