Dear,
On Wed, 16 Sep 2020 at 09:35, Steffen Rytter Postas <nc@scalehost.eu> wrote:
Toggle quote (6 lines)
> 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.
You are using Guix on foreign distro, right?Therefore, the concept of "installing applications as root" does notapply any more.There is _one_ version of Guix, the one you use as regular user.And as said before, "sudo guix pull" just updates the daemon and fortypical use-cases (not Guix developer), you can do that only each fullmoon. :-)
Toggle quote (4 lines)
> 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?
There is no argument against. You use case should work, you just needto set up correctly, with for example:
sudo guix pull -p /usr/
But it is not standard for Guix. That's why you need a bit of more work.
Otherwise, yes each user runs "guix pull" as their own user and neveruses the system-wide Guix.Each user specifies their own local channels. If the sysadmin wantsthat each user pulls with a specific channels file, the easiest is toadd a symlink from ~/.config/guix/current/channels.scm to say/etc/guix/channels.scm for all the users on the machine.
On the machine, 2 users can run different Guix and so installdifferent versions of the same packages. That's why it is importantto report the "guix describe" of the user.
Toggle quote (4 lines)
> 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 not sure there is an issue but an incorrect setup. :-)
Toggle quote (4 lines)
> 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.
I am not convinced it is a bug. But I can have wrong and miss something.
Toggle quote (3 lines)
> It does seem to me that this is indeed a bug, as Guix behaves> differently based upon who is executing it.
Yes, it is expected.
For example, I am running Guix on a Debian.There is: - the system-wide Guix version at version f6dfe42 (4 "guix pull" andlast on Sep 15 2020 01:42:11) - user kioo at the version 1a9af96 (1 "guix pull" and last on Apr 182020 20:13:23) - mine at the version 9e7b265 (44 "guix pull" and last on Sep 16 2020 11:28:36)
Well, the sysadmin did "guix pull" 4 times and me I did 44 times, soclearly the command 'guix' behaves differently based upon who isexecuting it.
For example, if the user kikoo run "guix install emacs" then they willinstall the version 26.3. and me instead wll install version 27.1,
If I want to install the same version as the user kikoo, I can do:
guix pull --commit=1a9af96 guix install emacs
or better:
guix time-machine --commit=1a9af96 -- install emacs
The first will create another generation and my version of Guix willbe at 1a9af96. Which is not a good Guix practise, IMHO.Instead, the second creates a temporary version of Guix and use it toinstall the package emacs; without polluting my version of guix.
Does it make sense?
All the best,simon