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.html&data=04%7C01%7CJohn.Bollinger%40stjude.org%7C44e7e297444d479661a508d979297044%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C637674042331996338%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=v5PpWlMn1cERhkW2aCOomNXbfdR2wMxh%2BhXfc73zeEo%3D&reserved=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.html&data=04%7C01%7CJohn.Bollinger%40stjude.org%7C44e7e297444d479661a508d979297044%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C637674042331996338%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YpY9Gx5v4Uh9rm2V4bMEJ3dJn8Sz1CZLn9vOWxd0PAQ%3D&reserved=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%2F&data=04%7C01%7CJohn.Bollinger%40stjude.org%7C44e7e297444d479661a508d979297044%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C637674042331996338%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5ZacbK4u%2BFwrv88QW%2FtUMK5UgMLbkkt%2B4xpMFWvC90
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 mea
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.)
