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 <xdg-boun...@lists.freedesktop.org> 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/<APPNAME>", "/etc/xdg/<APPNAME>" 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%2B4xpMFWvC90U%3D&reserved=0 Also the Freedesktop Flatpak list: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fflatpak&data=04%7C01%7CJohn.Bollinger%40stjude.org%7C44e7e297444d479661a508d979297044%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C637674042331996338%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wJLHRaOCPyNIi2LdGgPPtaoMAHYD0garQiyBFYy3KLs%3D&reserved=0 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Ffreedesktop-sdk%2Ffreedesktop-sdk&data=04%7C01%7CJohn.Bollinger%40stjude.org%7C44e7e297444d479661a508d979297044%7C22340fa892264871b677d3b3e377af72%7C0%7C0%7C637674042332006291%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NRWSjdLXrCUwcPHxXMxMcSnGVPNW8PKQe%2BhQVsmZja8%3D&reserved=0 (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.) ________________________________ Email Disclaimer: www.stjude.org/emaildisclaimer Consultation Disclaimer: www.stjude.org/consultationdisclaimer
