unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Prikler <leo.prikler@student.tugraz.at>
To: John Kehayias <john.kehayias@protonmail.com>
Cc: 50103@debbugs.gnu.org
Subject: bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS
Date: Wed, 18 Aug 2021 18:35:31 +0200	[thread overview]
Message-ID: <870c9fb6c492092ef3b5b41b007c160be423fc69.camel@student.tugraz.at> (raw)
In-Reply-To: <Tlcr3gCJjm_y5KwAunC3wsOlumzCogR6hjQM69CW_Db8jXCrLUDXtJNERP-oydByHC3iHq-qTTHTh8Fxs2134YEIjptx_RhIfouxY0eWxmk=@protonmail.com>

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





  reply	other threads:[~2021-08-18 16:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18  5:07 bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS John Kehayias via Bug reports for GNU Guix
2021-08-18  8:03 ` Leo Prikler
2021-08-18  9:28   ` Maxime Devos
2021-08-18  9:45     ` Leo Prikler
2021-08-18 14:27       ` John Kehayias via Bug reports for GNU Guix
2021-08-18 15:19         ` Leo Prikler
2021-08-18 16:06           ` John Kehayias via Bug reports for GNU Guix
2021-08-18 16:35             ` Leo Prikler [this message]
2021-08-18 17:53               ` John Kehayias via Bug reports for GNU Guix
2021-08-20  9:44               ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=870c9fb6c492092ef3b5b41b007c160be423fc69.camel@student.tugraz.at \
    --to=leo.prikler@student.tugraz.at \
    --cc=50103@debbugs.gnu.org \
    --cc=john.kehayias@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).