bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

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

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