bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

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

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:

> Hi,
>
> Am Mittwoch, den 18.08.2021, 11:28 +0200 schrieb Maxime Devos:
>
> > Leo Prikler schreef op wo 18-08-2021 om 10:03 [+0200]:
> >
> > > 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).

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