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

Previous Next

Full log

View this message in rfc822 format

From: John Kehayias <john.kehayias <at> protonmail.com>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>
Cc: 50103 <at> debbugs.gnu.org, Maxime Devos <maximedevos <at> telenet.be>
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 search-paths).

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

John

Previous Next

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