bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[John Kehayias via Bug reports for GNU Guix <bug-guix@gnu.org>]

Hi Leo,

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Wednesday, August 18th, 2021 at 11:19 AM, Leo Prikler  wrote:
[...]
> > > >
> > > > > 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'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).
>
> 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.
>

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

> > > > > 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.
> > > >
> > > > 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.
> > > >
> > > > 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.
> >
> > 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'm not sure about that myself but the answer is probably no.
>
> > 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 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.
>

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.

> > 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.)
>
> 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.
>

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.

> 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).
>

.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.

> 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]
>
> https://yhetil.org/guix-devel/eabe0cccdb377b1c573df88715d6aebf7bf7f80c.camel@student.tugraz.at/

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