GNU bug report logs - #50103
Pulseaudio doesn't export XDG_CONFIG_DIRS

Previous Next

Full log

Message #14 received at 50103 <at> debbugs.gnu.org (full text, mbox):

From: Leo Prikler <leo.prikler <at> student.tugraz.at>
To: Maxime Devos <maximedevos <at> telenet.be>, john.kehayias <at> protonmail.com, 
 50103 <at> debbugs.gnu.org
Subject: Re: bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS
Date: Wed, 18 Aug 2021 11:45:37 +0200

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

Regards

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.