From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 16 03:35:12 2020 Received: (at 42810) by debbugs.gnu.org; 16 Sep 2020 07:35:12 +0000 Received: from localhost ([127.0.0.1]:33067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kIRyB-00045F-LW for submit@debbugs.gnu.org; Wed, 16 Sep 2020 03:35:11 -0400 Received: from scalehost.eu ([108.61.99.179]:40030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kIRy9-000456-8C for 42810@debbugs.gnu.org; Wed, 16 Sep 2020 03:35:09 -0400 Received: from pop-os (unknown [89.239.193.119]) by scalehost.eu (Postfix) with ESMTPSA id 2C360FA0D9; Wed, 16 Sep 2020 07:35:07 +0000 (UTC) Message-ID: <634882b61652f958e44760e64179bcdc99481310.camel@scalehost.eu> Subject: Re: bug#42810: Guix doesn't follow all symlinks From: Steffen Rytter Postas To: zimoun Date: Wed, 16 Sep 2020 09:35:06 +0200 In-Reply-To: References: <867dsuzlr6.fsf@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.4-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 42810 Cc: 42810@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, ons, 16 09 2020 kl. 09:26 +0200, skrev zimoun: > Dear, > > On Wed, 16 Sep 2020 at 08:45, Steffen Rytter Postas > wrote: > > > > Well, I am not sure to understand why you want this setup since > > > “guix-daemon” needs (really) few updates and as regular user, > > > when > > > doing > > > “guix pull”, if there is major upgrade, then it will be announced > > > with > > > “guix pull –news”. We all like different tastes. :-) > > > > I also wanted to maintain only one copy of "guix" usable, instead > > of > > having one version of guix per user, which is a lot harder to > > maintain. > > But the point of Guix is: each user manages their own version, isn't > it? > From my point of view, it does not make sense to try to maintain only > one central copy, because in any case, each user can run: > > guix time-machine -C -- > guix time-machine --commit= -- > > so each user can install, remove, etc. any version of Guix (specified > by and ) independently of the version of "guix > time-machine". > > Well, I am not sure to understand the aim of the configuration you > want to. > This may well be the point of Guix, and maybe I'm' following too much of a classical paradigm, but for me on a classical Linux desktop system, it is much easier for me to just use _one_ version of Guix, regardless of using it as my own user, or installing applications as root. I'm not sure why this should _not_ work. What is the arguments against my use case? Is it that each user _MUST_ run `guix pull` as their own user and _NEVER_ use the system-wide Guix with local channels? > > > > So you need to have also in the correct symlinks with > > > ’lib/{guile,guix}’ > > > and others. > > > > How would I set this up? This happens on a default Guix setup > > following > > the standard installation guide for installing on a foreign > > distribution, and then setting up the channel configuration as > > mentioned. > > I do not know how you could setup your non-standard usage of Guix. > > Maybe you could try as root: > > sudo guix pull -p /usr > > then place /usr in the correct paths (PATH, LIBRARY_PATH, etc.) for > each user. However, it will be easy for one user to by-pass your > setup and use any version of Guix they wants: > > /usr/bin/guix pull -p /path/somewhere/to/user-home > > then the user can correctly set up the paths so that "guix" will > refer > to the one living at /path/somewhere/to/user-home/. > > Well, from my understanding, you are trying to set up Guix in the > paradigm of classic package manager, not in its "philosophy". > I do not mind being able to by-pass any setup I've made. This is for my own system(s) only, but the issue happens on any non-GuixSD system running Guix on a foreign distribution. I am aware there may be workarounds, and currently I'm using the workaround as specified in the bug report, but if this is _NOT_ a bug, then I shall continue to use my workaround. It does seem to me that this is indeed a bug, as Guix behaves differently based upon who is executing it. > > > > I have not investigated but I guess the issue you hit comes from > > > ’lib/guix/package.cache’, correctly see by > > > /var/guix/profiles/…/bin/guix’ but not all your other symlink > > > machinery. > > > > > > > This does make sense, if that is somehow only read from a non-store > > location (I'm not sure why it would be, that seems against all the > > point of guix in the first place). > > I am not sure to understand what you mean. > > > Do the explanations help? > > All the best, > simon >