[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

From: John Kehayias
Subject: bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS
Date: Wed, 18 Aug 2021 17:53:00 +0000

Hi Leo,

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

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

> 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

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.

> Am Mittwoch, den 18.08.2021, 16:06 +0000 schrieb John Kehayias:
> > Hi Leo,
> >
> > On Wednesday, August 18th, 2021 at 11:19 AM, Leo Prikler wrote:
> >
> > [...]
> >
> > .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.
> $(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.

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

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

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?

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

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 

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]