bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[John Kehayias via Bug reports for GNU Guix]

Hello,

A minor bug: I think Pulseaudio should have XDG_CONFIG_DIRS as an exported search path, as it includes a desktop file in /etc/xdg/autostart. This would be used by e.g. starting just a window manager and using something like dex to run autostart programs. Of course there are other ways to do this, but especially if pulseaudio is not in the default user or system profile then XDG_CONFIG_DIRS will not include pulseaudio.

Are there any downsides to including XDG_CONFIG_DIRS in the pulseaudio package? I haven't run across any other packages falling into this case as well, but I wouldn't be surprised for anything that supplies an autostart .desktop file.

Thanks,
John

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[Leo Prikler]

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.

Regards

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

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.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[Leo Prikler]

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

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[John Kehayias via Bug reports for GNU Guix]

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

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

John

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/

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[John Kehayias via Bug reports for GNU Guix]

Hi Leo,

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

On Wednesday, August 18th, 2021 at 11:19 AM, Leo Prikler  wrote:
[...]
> > > >
> > > > > 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.
>

Okay, just checking! I didn't see any workaround package, very few references to XDG_CONFIG_DIRS in our packages.

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

It does seem less universal. On a non-Guix system I see a handful of programs that keep default configurations there, things like ICC profiles, and of course autostart .desktop files.

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

And I think that is a shame, as profiles and manifests are such a great feature of Guix. The ability to compartmentalize package groups is very nice just on the organizational level, but does seem less than fully incorporated at this point. It is a shift from the non-Guix distro experience.

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

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

This is just a detail, but could always default to something that matches XDG even if XDG variables aren't available. Or maybe better to break away anyway since it is something a bit different. Details.

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

Yes, that seems like some options. Personally, I'm a fan of promoting (multiple) profiles to more fully first-class citizens in Guix, as that would fit well. E.g. having a canonical profile directory, or otherwise making it more baked into the system so you don't need to manually add scripts to loop over profiles.

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.

John

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[Leo Prikler]

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

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.

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

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.

Regards

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[John Kehayias via Bug reports for GNU Guix]

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

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[zimoun]

Hi,

On Wed, 18 Aug 2021 at 18:35, Leo Prikler <leo.prikler@student.tugraz.at> wrote:
> Am Mittwoch, den 18.08.2021, 16:06 +0000 schrieb John Kehayias:

>> .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, let open a new thread and resume the previous discussion should
nice.  From what I remember, the consensus had been (almost) reached and
none of us took the time to propose a draft patch. :-)

We could imagine a hierarchy where the profile are looked for––say
~/.cache/guix/profiles/ then ~/.config/guix/profiles then etc.––or an
environment variable to let the user have the control.  Whatever, we all
have an idea but nothing concrete to discussion the details. ;-)

From my understanding, set a central place where the profiles live would
be very helpful.  Having only one big profile slows down a lot of
operation when several ones ease the maintenance, IMHO.

Cheers,
simon

PS: Personally, I have profiles with my tools (Emacs, notmuch,
etc. )under ~/.config/guix/profiles and these profiles are generated
with manifests under ~/.config/guix/manifests/ (folder under Git).  Then
inside each project, I have a manifest file specific for the project,
then sometime the profile lives here, sometime I only use “guix
environment”, etc.