bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[Leo Prikler]

Hi John,

Am Mittwoch, den 18.08.2021, 14:27 +0000 schrieb John Kehayias:
> 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).
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 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.

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

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