From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 2x7qFzIwHWE6MgAAgWs5BA (envelope-from ) for ; Wed, 18 Aug 2021 18:07:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id EJP5EjIwHWH9DAAAbx9fmQ (envelope-from ) for ; Wed, 18 Aug 2021 16:07:14 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A79463D07 for ; Wed, 18 Aug 2021 18:07:12 +0200 (CEST) Received: from localhost ([::1]:49464 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mGO5v-0000o5-Gk for larch@yhetil.org; Wed, 18 Aug 2021 12:07:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48458) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGO5m-0000nY-Qh for bug-guix@gnu.org; Wed, 18 Aug 2021 12:07:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:45828) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mGO5m-0003oC-KY for bug-guix@gnu.org; Wed, 18 Aug 2021 12:07:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mGO5m-00017K-CW for bug-guix@gnu.org; Wed, 18 Aug 2021 12:07:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS Resent-From: John Kehayias Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 18 Aug 2021 16:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50103 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Leo Prikler Cc: 50103@debbugs.gnu.org, Maxime Devos Received: via spool by 50103-submit@debbugs.gnu.org id=B50103.16293028214287 (code B ref 50103); Wed, 18 Aug 2021 16:07:02 +0000 Received: (at 50103) by debbugs.gnu.org; 18 Aug 2021 16:07:01 +0000 Received: from localhost ([127.0.0.1]:57374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGO5k-000175-Er for submit@debbugs.gnu.org; Wed, 18 Aug 2021 12:07:00 -0400 Received: from mail-4322.protonmail.ch ([185.70.43.22]:50327) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGO5h-00016q-Nt for 50103@debbugs.gnu.org; Wed, 18 Aug 2021 12:06:59 -0400 Date: Wed, 18 Aug 2021 16:06:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1629302810; bh=Vn2+Ix04/XhADOw/5rbuaP0qa742u48miv25Y8nlXHw=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=SZF2hSyaAkmr/h38MAmCTpXomadIjlrzA35NuEQq0qR2KWWZoj6Wwr9E02mrIwURo 1RtgxiGebOtAp08O5yCUQNNskGylYqt6m3tGAPoQKC5F5/DbjVyELqfXfab2I9+PF/ KNNKvpeP77+E8ALe2CDtcIqyWlS3aEhdxmCM5tcA= Message-ID: In-Reply-To: References: <8260714867d007d924c151a18ff9c63950ab2fcd.camel@student.tugraz.at> <04f0f93cb3dd7fa70d940f200b00432eaf9004e9.camel@telenet.be> <459e9a0866a72bd3bf792d347e249f854e5654e1.camel@student.tugraz.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" Reply-to: John Kehayias X-ACL-Warn: , John Kehayias From: John Kehayias via Bug reports for GNU Guix X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1629302833; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Vn2+Ix04/XhADOw/5rbuaP0qa742u48miv25Y8nlXHw=; b=qVH74LsxCOy9GQe/bWAJq/OYdECkMFD6Rw+NwVeHLwT2VNm9Ssb0mD3IDb54+9pLNKiSXL dW6h2/2LqSMkkGPmCEMT+cYu4eeSjlQNBRXwvL/fTNyz0+RNN0bGxQXsWkWZjrJkv3gJuC h8Us6g8NSWUDACEuCGAwjS57v5KyPsNBN2h30gQEvDzayzH5WrHgJOrPxdAnc8MohIPG1F sZkLuHGv6wj//fJaZ7Z9Ew2BUmFLvtQTZtdQ5koa4e2XN6wJGSGpPOsd/zw+nBqrvC4neK 1jTkijXUkV01mrd6GoO/hbbe0TtVh9ocm+p8Dnj5qIBcLuE8XhUgpdq/B6iO6g== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1629302833; a=rsa-sha256; cv=none; b=o7/vTt3eCuMigzjEnv3kE5dX7oxC+gmJQGD6S27OY2LUH+8fWJSl8EsKCEhEZ0wSE+9HA3 /xsi9cagiSSPiGQKpN5bgTQ7iWM+9AP/7AJVgSFKztC0yj+bxWh6OOfMTPuUzM9obhKXNU L+CogJryGAaM6FvuIAMTwHNtvziCLS4Q7OINWQ6TuAho1/n1ala6eQ+RWTvvtdzmu6P3Fq Fd7kjA7jSPxZ34BYcVYY9Uh8FC8T1yJNvu8roCdaNb7m6Bz8NDLSILn5s746GzQhpMuNP3 ETMGvTYnwyyUB4VcjApL2FaKWXmQhn72q+ZvUFl4l+MVQU3XVFMcAepKJ34EVA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=protonmail.com header.s=protonmail header.b=SZF2hSya; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -1.42 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=protonmail.com header.s=protonmail header.b=SZF2hSya; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: A79463D07 X-Spam-Score: -1.42 X-Migadu-Scanner: scn0.migadu.com X-TUID: Ocgahrb8ZZUB Hi Leo, =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 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 referenc= es 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 > > > > > > > > $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 =E2=80=98thunked=E2=80=99 field would resolve the errors, at cost= of making > > > > > > > > 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 progra= ms 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 fea= ture of Guix. The ability to compartmentalize package groups is very nice j= ust 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 jus= t for root? took just a quick look) Personally, I prefer everything in .con= fig to keep the home folder cleaner, but we all know there's a strong mix o= f things like $HOME/.something and $HOME/.config/something. This is just a detail, but could always default to something that matches X= DG even if XDG variables aren't available. Or maybe better to break away an= yway 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.ca= mel@student.tugraz.at/ Yes, that seems like some options. Personally, I'm a fan of promoting (mult= iple) profiles to more fully first-class citizens in Guix, as that would fi= t well. E.g. having a canonical profile directory, or otherwise making it m= ore 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 k= now enough of the internals to have a helpful input here so far. Handling m= ultiple profiles together would help pull in some search-paths and maybe al= leviate #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 e= ach profile relying on env to find things, then at least in this case XDG_C= ONFG_DIRS still has to appear somewhere. Search paths in profiles could be = good, conceptually works for how profiles are used, to me. John