Pulseaudio doesn't export XDG_CONFIG_DIRS

Hello,

A minor bug: I think Pulseaudio should have XDG_CONFIG_DIRS as an exported search path, as it includes a desktop file in /etc/xdg/autostart. This would be used by e.g. starting just a window manager and using something like dex to run autostart programs. Of course there are other ways to do this, but especially if pulseaudio is not in the default user or system profile then XDG_CONFIG_DIRS will not include pulseaudio.

Are there any downsides to including XDG_CONFIG_DIRS in the pulseaudio package? I haven't run across any other packages falling into this case as well, but I wouldn't be surprised for anything that supplies an autostart .desktop file.

Thanks,

John

Hi John,

a lot of packages would do much better if they exported

XDG_CONFIG_DIRS. However, there is currently no way of doing so other

than copypasting the same snippet over and over and over and over. A

workaround -- if you need this in an environment -- is to also include

a package, that already has a search path on XDG_CONFIG_DIRS, like glib

(I think glib:bin works too).

I recently tried exporting XDG_CONFIG_DIRS as a variable from one

module, so that it can be referenced in others, but that led to a weird

recursive errors. It would be nice to find a good way of doing that,

though.

Regards

Leo Prikler schreef op wo 18-08-2021 om 10:03 [+0200]:

What do you think of defining the <search-path-specification>

$XDG_CONFIG_DIR in (guix search-paths) itself, next to $PATH? That seems

unlikely to lead to recursive errors.

Alternatively, I would guess that making 'search-paths' and

'native-search-paths' a ‘thunked’ field would resolve the errors,

at cost of making <package> objects use a bit more memory.

Greetings,

Maxime.

Hi,

Am Mittwoch, den 18.08.2021, 11:28 +0200 schrieb Maxime Devos:

Both sound like interesting proposals. Obviously, adding

$XDG_CONFIG_DIRS to (guix search-paths) would work in the short term,

but I think defining all interesting environment variables there is

probably not the best solution for the future. There's a few variables

that are used widely FSVO widely, but using them also implies having

some package as input, e.g. the cURL-related ones. XDG_CONFIG_DIRS

technically also falls in there, because you will have either xorg or

xdisorg imported. Therefore, I think I'd prefer a solution where

variables can be exported (and re-exported) from any module in the (gnu

packages) subtree.

Regards

Hi Leo and Maxime,

Thanks for discussing this. A few questions/clarifications (perhaps mostly because I'm still new here) below. I'm not familiar enough with the internals of guix search-paths, so my perspective is mostly from the end-user standpoint.

??????? Original Message ???????

On Wednesday, August 18th, 2021 at 5:45 AM, Leo Prikler wrote:

I'm slightly confused here: I only see XDG_DATA_DIRS in the glib package. I include glib to get that export actually (I have everything in profiles, nothing in the default user). Autostart files are in $XDG_CONFIG_DIRS/autostart. XDG_DATA_DIRS seems to come up the most and more needed it seems to me (based on what I have there in a desktop environment).

Is the case here that glib should have XDG_CONFIG_DIRS in it? Or does that only make sense in some other package that could then be included in a profile to get XDG_CONFIG_DIRS, similar to XDG_DATA_DIRS now?

I didn't see many references to XDG_CONFIG_DIRS in our current packages, mostly in some Lisp compilers and a few other random places. Slightly surprised it is not in more, but maybe packages that would normally put something in /etc/xdg (default for XDG_CONFIG_DIRS) have been configured otherwise.

I feel like my setup, from the cookbook, of having everything in profiles with the default user one being empty other than testing, has exposed a few related issues. What we are discussing might also have relevance to dbus files (see #48538), and perhaps to an older issue about paths and /etc/profile (#20255). (Not to bring up an old issue, but it was one that came up when searching for related issues in the past, which I skimmed.)

John

Hi John,

Am Mittwoch, den 18.08.2021, 14:27 +0000 schrieb John Kehayias:

Haha, my bad, yeah glib only provides XDG_DATA_DIRS. In that case I'm

not sure which one would be the canonical workaround package.

I'm not sure about that myself but the answer is probably no.

I think the likelier explanation is that XDG_CONFIG_DIRS is possibly

underused when compared to XDG_DATA_DIRS. Most packages store their

configuration -- if any -- in /etc/foo rather than /etc/xdg/foo. I'm

pretty certain that using /etc/xdg rather than /etc was an error on

XDG's part as XDG_CONFIG_HOME, which defaults to ~/.config makes much

more sense from an application writer's POV.

You are indeed right, multiple profiles are very badly supported by

Guix. Needing to jump through the hoops described in the cookbook in

the first place is in my eyes a clear enough indicator to support my

point.

Back in December of 2019, I wrote a proposal that would make it

possible to add user profiles next to the default profile [1]. It had

a few problems mostly related to underspecification and in the end went

nowhere. Earlier this year, around Guix Days, I thought I should

perhaps revive it, but for personal reasons didn't, instead

procrastinating. The only thing I now remember from back then was that

there was a certain push from fellow proponents to just use

$XDG_DATA_HOME/guix as this directory, but I'm still concerned whether

that is the correct approach (particularly since /etc/profile might not

know about the actual value of XDG_DATA_HOME in time).

I think that in order to truly make profiles splits work, we would

either have to make use of Guix at the lowest level, so as to merge

Emacs in one profile with a bunch of emacs-foo packages in another or

make search paths first-class citizens of profiles to allow for

amendments on top of what is already given by packages.

WDYT?

[1]

Hi Leo,

??????? Original Message ???????

On Wednesday, August 18th, 2021 at 11:19 AM, Leo Prikler wrote:

[...]

Okay, just checking! I didn't see any workaround package, very few references to XDG_CONFIG_DIRS in our packages.

It does seem less universal. On a non-Guix system I see a handful of programs that keep default configurations there, things like ICC profiles, and of course autostart .desktop files.

And I think that is a shame, as profiles and manifests are such a great feature of Guix. The ability to compartmentalize package groups is very nice just on the organizational level, but does seem less than fully incorporated at this point. It is a shift from the non-Guix distro experience.

.config/guix is hardcoded in a few places already isn't it? (or is that just for root? took just a quick look) Personally, I prefer everything in .config to keep the home folder cleaner, but we all know there's a strong mix of things like $HOME/.something and $HOME/.config/something.

This is just a detail, but could always default to something that matches XDG even if XDG variables aren't available. Or maybe better to break away anyway since it is something a bit different. Details.

Yes, that seems like some options. Personally, I'm a fan of promoting (multiple) profiles to more fully first-class citizens in Guix, as that would fit well. E.g. having a canonical profile directory, or otherwise making it more baked into the system so you don't need to manually add scripts to loop over profiles.

I suppose that still leaves the question of search paths. I don't think I know enough of the internals to have a helpful input here so far. Handling multiple profiles together would help pull in some search-paths and maybe alleviate #48538 (dbus)? Would then /etc be constructed from all the profiles together (by passing this XDG_CONFIG_DIRS issue)? If it is still /etc in each profile relying on env to find things, then at least in this case XDG_CONFG_DIRS still has to appear somewhere. Search paths in profiles could be good, conceptually works for how profiles are used, to me.

John

Hi John,

For the record, you should try to cite in a way, that lines don't get

broken. I have no idea why this is happening

Am Mittwoch, den 18.08.2021, 16:06 +0000 schrieb John Kehayias:

$(HOME)/.config is particularly hard-coded in the current /etc/profile,

which is why I dub it "fake XDG conformance". I personally disagree

with the use for $(HOME)/.config for software packages.

For context, `guix package --search-paths' would implement the merged

approach IIUC, but then you would have to invoke guix from

/etc/profile, which reportedly is not every person's tea. You could

still manually source $GUIX_PROFILE/etc/profile, but would then get an

incomplete view depending on what your profiles look like.

As for the XDG_CONFIG_DIRS, I don't think your scenario is the only

possible one, but with things being as they are currently, it is among

the likeliest outcomes. Another approach would be to define "precious"

search paths, which would be considered even if not explicitly

mentioned by any package/profile. (I think this somewhat overlaps

with/complements search paths as a first-class manifest citizen). I'm

just throwing out ideas here, so you shouldn't necessarily take any of

them as *the* solution to all our problems or something that can be

easily implemented given the status quo, but if you want, you can take

some inspiration from them or try out your own (thought) experiments.

Regards

Hi Leo,

??????? Original Message ???????

On Wednesday, August 18th, 2021 at 12:35 PM, Leo Prikler wrote:

I just noticed that too, sorry. Seems protonmail likes to wrap at a shorter length and introduces these blank lines. Guess it is about time I get this account into mu4e.

Well, it is all a bit of a mess. Off topic, but I try to use literate org files and stow to wrangle everything.

That was the discussion in #20255 that was never resolved.

In this case, I don't think any combination of `guix package --search-paths` will update XDG_CONFIG_DIRS since it is not in the native-search-paths of any of my included packages, as far as I can tell. I do see it included in qtbase, but I'd rather avoid pulling that in unless I actually have qt packages (which I probably will at some point). Just checking, and installing qtbase would indeed add XDG_CONFIG_DIRS to the /etc/profile as expected.

Is there a reason qtbase has it but nothing on the glib/gtk/xorg side?

I understand, this is a longer-term direction to discuss (I can certainly work around this issue in many ways). I think the related dbus issue #48538 is more noticeable, but all point towards better sorting out how we treat profiles and search-paths. My process as a new Guix user is to get everything working as I like it, and then try to reduce the edge case workarounds I've had to put in (a related one is #44997, for packages that may put things in /etc/profile.d).

I think it would be good to get some overall input and direction for what people would like as the next steps in how we manage profiles (and search-paths).

Thanks for the discussion so far, hopefully we can get some broad design choices and end goals in mind to then work out details.

John

Hi,

On Wed, 18 Aug 2021 at 18:35, Leo Prikler <leo.prikler@student.tugraz.at> wrote:

Well, let open a new thread and resume the previous discussion should

nice. From what I remember, the consensus had been (almost) reached and

none of us took the time to propose a draft patch. :-)

We could imagine a hierarchy where the profile are looked for––say

~/.cache/guix/profiles/ then ~/.config/guix/profiles then etc.––or an

environment variable to let the user have the control. Whatever, we all

have an idea but nothing concrete to discussion the details. ;-)

From my understanding, set a central place where the profiles live would

be very helpful. Having only one big profile slows down a lot of

operation when several ones ease the maintenance, IMHO.

Cheers,

simon

PS: Personally, I have profiles with my tools (Emacs, notmuch,

etc. )under ~/.config/guix/profiles and these profiles are generated

with manifests under ~/.config/guix/manifests/ (folder under Git). Then

inside each project, I have a manifest file specific for the project,

then sometime the profile lives here, sometime I only use “guix

environment”, etc.