* Should I upgrade root user's guix too? @ 2017-09-22 11:08 Attic Hermit 2017-09-23 7:47 ` Chris Marusich 0 siblings, 1 reply; 15+ messages in thread From: Attic Hermit @ 2017-09-22 11:08 UTC (permalink / raw) To: help-guix I use guix for using the softwares that Parabola GNU+Linux doesn't provide. Everything works great, but I have a question on the upgrade of guix itself. I regularly do `guix pull && guix package -u` in my default user, but I rarely do it in root user. I don't know if I'm right, but the guix build users runs the guix of the version of root, so if I don't upgrade the guix of root, that will stay on the old version for good. Therefore, the guix of root should be upgraded as well, when the guix of the default user is upgraded; Am I right? If upgrading the root's guix is valid, then which guix should be upgraded before? I usually upgrade non-root user's guix before and then root's. I couldn't find a related topic on the manual, so I'm little bit confused. -- Attic Hermit ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-22 11:08 Should I upgrade root user's guix too? Attic Hermit @ 2017-09-23 7:47 ` Chris Marusich 2017-09-23 8:17 ` Attic Hermit 0 siblings, 1 reply; 15+ messages in thread From: Chris Marusich @ 2017-09-23 7:47 UTC (permalink / raw) To: Attic Hermit; +Cc: help-guix [-- Attachment #1: Type: text/plain, Size: 1617 bytes --] Attic Hermit <fjdksl@cock.li> writes: > I use guix for using the softwares that Parabola GNU+Linux doesn't > provide. Everything works great, but I have a question on the upgrade of > guix itself. > > I regularly do `guix pull && guix package -u` in my default user, but I > rarely do it in root user. I don't know if I'm right, but the guix build > users runs the guix of the version of root, so if I don't upgrade the > guix of root, that will stay on the old version for good. Therefore, the > guix of root should be upgraded as well, when the guix of the default > user is upgraded; Am I right? > > If upgrading the root's guix is valid, then which guix should be > upgraded before? I usually upgrade non-root user's guix before > and then root's. > > I couldn't find a related topic on the manual, so I'm little bit > confused. You should run "guix pull" for both root and your non-privileged user(s). The version of Guix deployed for root is the version of Guix that will be used when running commands like "guix system reconfigure" as root. If you don't do "guix pull" as root, then whenever you run "guix" as root, you'll be using out of date Guix code, which includes the package definitions that come with Guix. The manual discusses the fact that "guix pull" only updates the Guix copy for the user who runs it (info '(guix) Invoking guix pull'). You might need to use sudo's "-H, --set-home" option to ensure that the guix command updates the right symlink (you'll probably need to do that only if the command "sudo env | grep HOME" produces no output). -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-23 7:47 ` Chris Marusich @ 2017-09-23 8:17 ` Attic Hermit 2017-09-23 9:18 ` Chris Marusich 0 siblings, 1 reply; 15+ messages in thread From: Attic Hermit @ 2017-09-23 8:17 UTC (permalink / raw) To: Chris Marusich; +Cc: help-guix Thanks for your reply. > You should run "guix pull" for both root and your non-privileged > user(s). The version of Guix deployed for root is the version of Guix > that will be used when running commands like "guix system reconfigure" > as root. If you don't do "guix pull" as root, then whenever you run > "guix" as root, you'll be using out of date Guix code, which includes > the package definitions that come with Guix. The manual discusses the > fact that "guix pull" only updates the Guix copy for the user who runs > it (info '(guix) Invoking guix pull'). I use Guix, but not GuixSD, only on the non-privileged user and there's no package installed but guix on the root user. So technically I can't use `guix system' command, and won't run `guix' command on the root shell interactively. Then the reason that I should pull and upgrade the guix profile of the root user is for implicit executions of the guix as the root user. And the package definition is one of that implicit executions... Is it right? Then I should run `guix pull && guix package -u' _as the root user_ *before* have done it as a non-privileged user, because when the packages are upgraded, the package definitions should be up to date. And the system should be *rebooted* or *restart* the guix build daemon which, in fact, is using the guix binary that the root user has. Is my understanding correct? -- Attic Hermit ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-23 8:17 ` Attic Hermit @ 2017-09-23 9:18 ` Chris Marusich 2017-09-23 13:05 ` Attic Hermit 2017-09-23 13:22 ` Adonay Felipe Nogueira 0 siblings, 2 replies; 15+ messages in thread From: Chris Marusich @ 2017-09-23 9:18 UTC (permalink / raw) To: Attic Hermit; +Cc: help-guix [-- Attachment #1: Type: text/plain, Size: 4647 bytes --] Attic Hermit <fjdksl@cock.li> writes: > I use Guix, but not GuixSD, only on the non-privileged user and there's > no package installed but guix on the root user. I see. I incorrectly assumed you were using GuixSD. It sounds like you've followed the steps described in the manual under "(guix) Binary Installation". I see that you're running Guix on a foreign distro. > Then the reason that I should pull and upgrade the guix profile of the > root user is for implicit executions of the guix as the root user. And > the package definition is one of that implicit executions... Is it > right? The reason you should still run "guix pull" as root in this case is to ensure that when your system boots and starts guix-daemon, it starts an up-to-date version of the daemon, including any security patches and the like for any dependencies guix-daemon uses. If you've followed the manual correctly, then I believe your system should be starting the guix-daemon executable that is installed in root's profile. Because the executable lives in root's profile, if you don't run "guix pull" as root and then run "guix package -u ." (or equivalent) as root to update the guix-daemon that is installed there, you will never wind up using a more up-to-date version of guix-daemon. The package definitions are independent of which version of the guix-daemon is being used. When a non-privileged user alice runs a command like "guix package -i hello" to install GNU Hello, she is using the package definitions that were installed by the latest "guix pull" that was run as the alice user (these package definitions live in the store, in a directory pointed to by the ~alice/.config/guix/latest symlink). When alice invokes the guix command to install the hello package, the guix command essentially translates the package definition into a derivation, and then asks the guix-daemon (via remote procedure calls) to build that derivation. The translation from package definition to derivation happens in alice's "guix" process, which is independent of the "guix-daemon" process. Her "guix" process communicates only via remote procedure calls with the "guix-daemon" process. The guix-daemon has no knowledge of the "package" abstraction, and it doesn't need to know about packages. For this reason, the guix-daemon doesn't necessarily need to be updated in order to build more up-to-date packages. The guix-daemon just knows how to do basic things related to the store like add files, build derivations, perform garbage collection, etc. It is the package definitions that are deployed to alice's home directory (via her latest invocation of "guix pull") that will determine which versions of packages get installed when alice runs "guix package -i", regardless of which version of the guix-daemon happens to be running. The same is true for any other user (including root, actually). > Then I should run `guix pull && guix package -u' _as the root user_ > *before* have done it as a non-privileged user, because when the > packages are upgraded, the package definitions should be up to date. No, the order does not matter. If alice runs those commands before root does, then alice will simply be able to install up-to-date packages before root can. That is normal and expected for the reasons described above. With Guix, each user independently manages their own installation of Guix. If two users run "guix pull" at different times, they might very well wind up using different package definitions. The ability for two different un-privileged users to independently install different versions of software at the same time without conflict is a feature of Guix (and Nix) that other package managers usually don't provide. > And the system should be *rebooted* or *restart* the guix build daemon > which, in fact, is using the guix binary that the root user has. Yes, you should restart the guix-daemon process. One way to do that is to reboot. However, for the reasons described above, alice will be able to install up-to-date software after running "guix pull" even if the guix-daemon process is old or hasn't yet been restarted. And the only reason you ought to run "guix pull && guix package -u ." as root is to ensure that the guix-daemon - which happens to be installed in root's profile - is up-to-date. If root had zero packages installed in root's profile, then there would be no point in running "guix pull && guix package -u ." as root at all. I hope that helps clarify things! I also found this topic a bit confusing at first. -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-23 9:18 ` Chris Marusich @ 2017-09-23 13:05 ` Attic Hermit 2017-09-23 13:22 ` Adonay Felipe Nogueira 1 sibling, 0 replies; 15+ messages in thread From: Attic Hermit @ 2017-09-23 13:05 UTC (permalink / raw) To: Chris Marusich; +Cc: help-guix > When alice invokes the guix command to install the hello package, the > guix command essentially translates the package definition into a > derivation, and then asks the guix-daemon (via remote procedure calls) > to build that derivation. > guix-daemon has no knowledge of the "package" abstraction, and it > doesn't need to know about packages. For this reason, the guix-daemon > doesn't necessarily need to be updated in order to build more > up-to-date packages. The guix-daemon just knows how to do basic > things related to the store like add files, build derivations, perform > garbage collection, etc. To summarize, `guix pull && guix package -u' on the root user is basically for the sake of the features to do basic things, when the root user's guix profile is only for the guix-daemon. Thanks for your precise explanation! All things are clear now. I'll give a link to this conversation if someone encounter and ask the same confusion. Your mail was that helpful. :) -- Attic Hermit ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-23 9:18 ` Chris Marusich 2017-09-23 13:05 ` Attic Hermit @ 2017-09-23 13:22 ` Adonay Felipe Nogueira 2017-09-24 18:01 ` Quiliro Ordonez Baca 2017-09-26 18:10 ` Oleg Pykhalov 1 sibling, 2 replies; 15+ messages in thread From: Adonay Felipe Nogueira @ 2017-09-23 13:22 UTC (permalink / raw) To: help-guix I think root profile doesn't have 0 (zero) packages installed. It has guix. ;) As a personal preference, I always do: # guix pull && guix package -u ... as root, and then: $ guix pull && guix package -u ... as normal user Chris Marusich <cmmarusich@gmail.com> writes: > > I see. I incorrectly assumed you were using GuixSD. It sounds like > you've followed the steps described in the manual under "(guix) Binary > Installation". I see that you're running Guix on a foreign distro. > > > The reason you should still run "guix pull" as root in this case is to > ensure that when your system boots and starts guix-daemon, it starts an > up-to-date version of the daemon, including any security patches and the > like for any dependencies guix-daemon uses. If you've followed the > manual correctly, then I believe your system should be starting the > guix-daemon executable that is installed in root's profile. Because the > executable lives in root's profile, if you don't run "guix pull" as root > and then run "guix package -u ." (or equivalent) as root to update the > guix-daemon that is installed there, you will never wind up using a more > up-to-date version of guix-daemon. > > The package definitions are independent of which version of the > guix-daemon is being used. When a non-privileged user alice runs a > command like "guix package -i hello" to install GNU Hello, she is using > the package definitions that were installed by the latest "guix pull" > that was run as the alice user (these package definitions live in the > store, in a directory pointed to by the ~alice/.config/guix/latest > symlink). When alice invokes the guix command to install the hello > package, the guix command essentially translates the package definition > into a derivation, and then asks the guix-daemon (via remote procedure > calls) to build that derivation. > > The translation from package definition to derivation happens in alice's > "guix" process, which is independent of the "guix-daemon" process. Her > "guix" process communicates only via remote procedure calls with the > "guix-daemon" process. The guix-daemon has no knowledge of the > "package" abstraction, and it doesn't need to know about packages. For > this reason, the guix-daemon doesn't necessarily need to be updated in > order to build more up-to-date packages. The guix-daemon just knows how > to do basic things related to the store like add files, build > derivations, perform garbage collection, etc. It is the package > definitions that are deployed to alice's home directory (via her latest > invocation of "guix pull") that will determine which versions of > packages get installed when alice runs "guix package -i", regardless of > which version of the guix-daemon happens to be running. The same is > true for any other user (including root, actually). > > > No, the order does not matter. If alice runs those commands before root > does, then alice will simply be able to install up-to-date packages > before root can. That is normal and expected for the reasons described > above. With Guix, each user independently manages their own > installation of Guix. If two users run "guix pull" at different times, > they might very well wind up using different package definitions. The > ability for two different un-privileged users to independently install > different versions of software at the same time without conflict is a > feature of Guix (and Nix) that other package managers usually don't > provide. > > > Yes, you should restart the guix-daemon process. One way to do that is > to reboot. However, for the reasons described above, alice will be able > to install up-to-date software after running "guix pull" even if the > guix-daemon process is old or hasn't yet been restarted. And the only > reason you ought to run "guix pull && guix package -u ." as root is to > ensure that the guix-daemon - which happens to be installed in root's > profile - is up-to-date. If root had zero packages installed in root's > profile, then there would be no point in running "guix pull && guix > package -u ." as root at all. > > I hope that helps clarify things! I also found this topic a bit > confusing at first. -- - https://libreplanet.org/wiki/User:Adfeno - Palestrante e consultor sobre /software/ livre (não confundir com gratis). - "WhatsApp"? Ele não é livre. Por favor, use o GNU Ring ou o Tox. - Contato: https://libreplanet.org/wiki/User:Adfeno#vCard - Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft Office, MP3, MP4, WMA, WMV. - Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF (apenas sem DRM), PNG, TXT, WEBM. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-23 13:22 ` Adonay Felipe Nogueira @ 2017-09-24 18:01 ` Quiliro Ordonez Baca 2017-09-25 21:12 ` Chris Marusich 2017-09-26 18:10 ` Oleg Pykhalov 1 sibling, 1 reply; 15+ messages in thread From: Quiliro Ordonez Baca @ 2017-09-24 18:01 UTC (permalink / raw) To: Adonay Felipe Nogueira; +Cc: help-guix Adonay Felipe Nogueira <adfeno@hyperbola.info> writes: > I think root profile doesn't have 0 (zero) packages installed. It has > guix. ;) > > As a personal preference, I always do: > > # guix pull && guix package -u > > ... as root, and then: > > $ guix pull && guix package -u > > ... as normal user Very nice thread: very descriptive and enlighting. Thank you. I have just one question: In GuixSD, the root user needs updating for the Guix-daemon to update as you say is needed on a foreign distro? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-24 18:01 ` Quiliro Ordonez Baca @ 2017-09-25 21:12 ` Chris Marusich 0 siblings, 0 replies; 15+ messages in thread From: Chris Marusich @ 2017-09-25 21:12 UTC (permalink / raw) To: Quiliro Ordonez Baca; +Cc: help-guix [-- Attachment #1: Type: text/plain, Size: 10269 bytes --] Quiliro Ordonez Baca <quiliro@riseup.net> writes: > Very nice thread: very descriptive and enlighting. Thank you. > > I have just one question: In GuixSD, the root user needs updating for the > Guix-daemon to update as you say is needed on a foreign distro? Basically, yes, on a foreign distro, the reason you should run "guix pull" and "guix package -u ." as root is to ensure that guix-daemon is up-to-date. This assumes that the "guix" package (which provides the guix-daemon executable) is installed in the root user's profile, and that you have configured your system so that at boot, it automatically starts the guix-daemon that is installed in root's profile (info '(guix) Binary Installation'). The truth is, it's a little complicated. With the current implementation, the behavior can be influenced through environment variables, so the exact answer to the question of "What should I do?" depends on how your system is configured and on how you invoke the "guix" program.I've just spent some time refreshing myself on how this works, so I'll take a few minutes to try to clarify the behavior. Let's take a look at the "guix" launcher script to see what happens when we invoke a command like "guix package -i" or "guix pull". If you look at the guix launcher script [1], you'll find that it invokes the following procedure: (define (maybe-augment-load-paths!) (unless (getenv "GUIX_UNINSTALLED") (let ((module-dir (config-lookup "guilemoduledir")) (object-dir (config-lookup "guileobjectdir"))) (push! module-dir %load-path) (push! object-dir %load-compiled-path)) (let ((updates-dir (and=> (or (getenv "XDG_CONFIG_HOME") (and=> (getenv "HOME") (cut string-append <> "/.config"))) (cut string-append <> "/guix/latest")))) (when (and updates-dir (file-exists? updates-dir)) ;; XXX: Currently 'guix pull' puts both .scm and .go files in ;; UPDATES-DIR. (push! updates-dir %load-path) (push! updates-dir %load-compiled-path))))) This procedure modifies the Guile load paths (info '(guile) Load Paths'), which is the mechanism by which Guile finds modules to use. Specifically, if XDG_CONFIG_HOME is set, the procedure adds $XDG_CONFIG_HOME/guix/latest to the front of the load paths; if XDG_CONFIG_HOME is not set, but HOME is set, then the procedure adds $HOME/.config/guix/latest to the front of the load paths; if neither XDG_CONFIG_HOME nor HOME are set (or if one of them was set, but it points to a non-existent file), then the procedure takes no action. After the launcher script (maybe) augments the load paths, it invokes the following procedure: (define (run-guix-main) (let ((guix-main (module-ref (resolve-interface '(guix ui)) 'guix-main))) (bindtextdomain "guix" (config-lookup "localedir")) (bindtextdomain "guix-packages" (config-lookup "localedir")) (apply guix-main (command-line)))) Note that it uses the procedure resolve-interface to find the module named (guix ui). Because the program previously added a directory such as $HOME/.config/guix/latest to front of the load paths, that is where Guile will find the (guix ui) module [2]. Within (guix ui), we use similar tricks to run the requested command. What is the point of doing it this way? Well, consider what happens when a user alice runs "guix package -i hello". In a normal setup, the "guix" command that alice invokes does not reside in Alice's profile; it resides elsewhere (run "which guix" to see where!). On GuixSD, this is normally /run/current-system/profile/bin/guix, and on a foreign distro, this might be /usr/local/bin/guix (a symlink to /var/guix/profiles/per-user/root/guix-profile/bin/guix). As described above, this "guix" command is a very thin shim; its sole purpose is to find the (guix ui) module and run the guix-main procedure defined there. Let's assume that alice runs "guix package -i hello" in an environment in which XDG_CONFIG_HOME is unset, but HOME is set to /home/alice. This is a common configuration, and it's the one I have on both my GuixSD system and on my Ubuntu system. Now, when alice runs "guix package -i hello" in this environment, the "guix" executable will wind up finding (guix ui) under /home/alice/.config/guix/latest. Because the "guix" executable is simply a thin shim as described above, it will find (guix ui) in that location regardless of where the "guix" executable happens to reside. Likewise, the guix-main procedure defined in (guix ui) will search for the (guix scripts package) module, it will also find it under /home/alice/.config/guix/latest, and it will delegate control to the guix-package procedure defined there [3]. As a result, even though alice's invocation of "guix package -i hello" might start by invoking a "guix" launcher script that resides outside of her home directory (e.g., at /usr/local/bin/guix), all of the code which defines the business logic of the "guix package" command will come from /home/alice/.config/guix/latest. When I say "all of the code which defines the business logic of the "guix package" command, I mean everything in (guix ui), (guix scripts package), all of the package definitions in modules with names like (gnu packages *), and all of the supporting Guix code that these Guile modules might use (e.g., (guix monads)). If a different user bob runs the same "guix package -i hello" command using the same "guix" executable as alice, then (assuming that in bob's environment, XDG_CONFIG_HOME is unset, and HOME is set to /home/bob) all the code which defines the business logic will come from /home/bob/.config/guix/latest. In this way, alice and bob have two independent installations of Guix, including the package definitions. When alice runs "guix package -i hello", she'll use her package definition for GNU Hello, and when bob runs it, he'll use his. "guix pull" is just another example of this. When alice runs "guix pull," it will ultimately run code from the (guix scripts pull) module defined in /home/alice/.config/guix/latest/guix/scripts/pull.scm. The code for (guix scripts pull) is currently designed to deploy the latest version of Guix (which contains all the modules, including the various scripts and the package definitions) to /home/alice/.config/guix/latest. It does this by downloading a more recent version, compiling it, and then flipping the /home/alice/.config/guix/latest symlink to point to the newly built version. Once this is complete, every command that alice runs, like "guix package -i hello", will use the new code (and new package definitions) that have been installed to /home/alice/.config/guix/latest. However, if bob runs the same command, he will continue to use whatever version of the code (and package definitions) that he was using before; it will not change for bob until bob runs "guix pull" himself. The root user is no different. Assuming a normal setup, the root user has a deployment of Guix under /root/.config/guix/latest, which can only be updated by running "guix pull" as root. Because the delegation mechanism described above relies on indirection via environment variables, it's possible that if you configure your system differently, things might behave differently. For example, on my Ubuntu machine, by default sudo is configured so that it will not change the HOME environment variable. As a result, if a user named alice runs "sudo guix pull" on my Ubuntu machine, it will cause /home/alice/.config/guix/latest to become a symlink owned by root, which is not what I intended. For this reason, on my Ubuntu machine I always run "sudo -H guix pull" instead of "sudo guix pull" when I want to update root's Guix installation (this causes sudo to set the HOME environment variable to /root; see 'man 8 sudo' for details). On GuixSD, this same problem does not occur (because sudo is already configured to set HOME to /root). In any case, you should test on your own system and figure out what environment variables are set in various situations. You can find out easily by running commands like "env" and "sudo env". On GuixSD, the guix-daemon is usually deployed at the system level (the guix-service-type implicitly installs the guix package to the system profile [4]). Therefore, on GuixSD, you upgrade the guix-daemon like you would upgrade any other part of the overall system: by running "guix system reconfigure" as root. On a foreign distro, the guix-daemon is usually deployed in root's profile. Therefore, on a foreign distro, you upgrade the guix-daemon like you would upgrade any other package in root's profile: by running "guix package -u ." as root. Regardless of whether you use GuixSD or a foreign distro, when you run a "guix" command as root, it will usually use whatever script implementations and package definitions are present in root's deployment of Guix, so before you run those commands as root, you should first run "guix pull" as root to ensure that you're using the latest and greatest. Note that in the future, the behavior of "guix pull" is likely to change [5]. I hope my attempt to explain things has helped to clarify how it works today and how it enables multiple users to have independent installations of Guix (including package definitions). I hope it helps you understand when you should run what commands. If anything is unclear, just remember that you can always look into the source code (it's free software, after all!), and the people on the email list or IRC are usually very helpful. Footnotes: [1] https://git.savannah.gnu.org/cgit/guix.git/tree/scripts/guix.in [2] https://git.savannah.gnu.org/cgit/guix.git/tree/guix/ui.scm [3] https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/package.scm [4] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/base.scm [5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22629 -- Chris [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-23 13:22 ` Adonay Felipe Nogueira 2017-09-24 18:01 ` Quiliro Ordonez Baca @ 2017-09-26 18:10 ` Oleg Pykhalov 2017-09-27 2:04 ` Attic Hermit 2017-10-05 14:47 ` Hartmut Goebel 1 sibling, 2 replies; 15+ messages in thread From: Oleg Pykhalov @ 2017-09-26 18:10 UTC (permalink / raw) To: Adonay Felipe Nogueira; +Cc: help-guix Adonay Felipe Nogueira <adfeno@hyperbola.info> writes: > As a personal preference, I always do: > > # guix pull && guix package -u > > ... as root, and then: > > $ guix pull && guix package -u > > ... as normal user I wrote a little script to not compile 2 times :-) After running "guix pull" with regular user run this with sudo. #!/bin/sh GUIX_LATEST=/root/.config/guix/latest unlink $GUIX_LATEST && ln -s $(readlink $HOME/.config/guix/latest) $GUIX_LATEST ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-26 18:10 ` Oleg Pykhalov @ 2017-09-27 2:04 ` Attic Hermit 2017-09-27 2:48 ` Attic Hermit 2017-10-05 14:47 ` Hartmut Goebel 1 sibling, 1 reply; 15+ messages in thread From: Attic Hermit @ 2017-09-27 2:04 UTC (permalink / raw) To: Oleg Pykhalov; +Cc: help-guix Oleg Pykhalov <go.wigust@gmail.com> writes: > #!/bin/sh > GUIX_LATEST=/root/.config/guix/latest > unlink $GUIX_LATEST && ln -s $(readlink $HOME/.config/guix/latest) $GUIX_LATEST Nice tip. I've been annoyed about the fact that root compiles almost same definitions once again after a non-priv user has done. But I wonder, in that sense, if root user has only "guix" package which should be located on the non-priv user, then don't we just replace root's profile into the one of the non-privileged user? like this: #!/bin/sh ROOT_LATEST=/root/.config/guix/latest ROOT_PROFILE=/root/.guix-profile USER_LATEST=/home/alice/.config/guix/latest USER_PROFILE=/home/alice/.guix-profile unlink $ROOT_LATEST && ln -s $(readlink $USER_LATEST) $ROOT_LATEST unlink $ROOT_PROFILE && ln -s $(readlink $USER_PROFILE) $ROOT_PROFILE Once you've done this, root won't need to `guix pull && guix package -u' anymore because the profile of the user is the same one that root has. It'll cause severe security problems because the non-priv user will be able to manipulate root's system through guix, but theoretically it should work. (I assume that guix profile is user-agnostic. If it isn't, please correct my error.) Root would get redundant packages, but it wouldn't matter because the only package root will use is guix and it won't be influenced. Root will lose its generation history, but will get and share user's history instead. P.S. I know that only changing the path of package definitions is enough to saving a time because guix will graft the packages which are already installed in almost no time, but just for the curiosity. -- Attic Hermit ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-27 2:04 ` Attic Hermit @ 2017-09-27 2:48 ` Attic Hermit 2017-09-30 0:38 ` Oleg Pykhalov 0 siblings, 1 reply; 15+ messages in thread From: Attic Hermit @ 2017-09-27 2:48 UTC (permalink / raw) To: Oleg Pykhalov; +Cc: help-guix Attic Hermit <fjdksl@cock.li> writes: >> #!/bin/sh >> GUIX_LATEST=/root/.config/guix/latest >> unlink $GUIX_LATEST && ln -s $(readlink $HOME/.config/guix/latest) $GUIX_LATEST To be sure your tip, I read the part of source code of guix pull and try to understand what it really do: http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/pull.scm and it seems that it only builds latest guix and make a symlink to ~/.config/guix/latest. Is that all? I'm little nervous that if I've missed something. If it is correct, then I can use your tip without doubt. -- Attic Hermit ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-27 2:48 ` Attic Hermit @ 2017-09-30 0:38 ` Oleg Pykhalov 2017-09-30 3:47 ` Attic Hermit 0 siblings, 1 reply; 15+ messages in thread From: Oleg Pykhalov @ 2017-09-30 0:38 UTC (permalink / raw) To: Attic Hermit; +Cc: help-guix Hello Attic, Attic Hermit <fjdksl@cock.li> writes: > Attic Hermit <fjdksl@cock.li> writes: > >>> #!/bin/sh >>> GUIX_LATEST=/root/.config/guix/latest >>> unlink $GUIX_LATEST && ln -s $(readlink $HOME/.config/guix/latest) $GUIX_LATEST > > To be sure your tip, I read the part of source code of guix pull and try > to understand what it really do: > http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/pull.scm > > and it seems that it only builds latest guix and make a symlink to > ~/.config/guix/latest. Is that all? I'm little nervous that if I've > missed something. If it is correct, then I can use your tip without > doubt. I got this idea after reading ‘(guix) Invoking guix pull’. (1) Under the hood, ‘guix pull’ updates the ‘~/.config/guix/latest’ symbolic link to point to the latest Guix, and the ‘guix’ command loads code from there. Currently, the only way to roll back an invocation of ‘guix pull’ is to manually update this symlink to point to the previous Guix. Some folks just do ‘/root/.config/guix/latest -> ~/.config/guix/latest’ symlink. But I like to have a script which I could run manually as needed. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-30 0:38 ` Oleg Pykhalov @ 2017-09-30 3:47 ` Attic Hermit 0 siblings, 0 replies; 15+ messages in thread From: Attic Hermit @ 2017-09-30 3:47 UTC (permalink / raw) To: Oleg Pykhalov; +Cc: help-guix > I got this idea after reading ‘(guix) Invoking guix pull’. > > (1) Under the hood, ‘guix pull’ updates the ‘~/.config/guix/latest’ > symbolic link to point to the latest Guix, and the ‘guix’ command > loads code from there. Currently, the only way to roll back an > invocation of ‘guix pull’ is to manually update this symlink to > point to the previous Guix. > > Some folks just do ‘/root/.config/guix/latest -> ~/.config/guix/latest’ > symlink. But I like to have a script which I could run manually as > needed. Oleg, Thank you! I've forgotten about that paragraph I read a long time ago. Thanks for your reminding me. Have a nice day! ;) -- Attic Hermit ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-09-26 18:10 ` Oleg Pykhalov 2017-09-27 2:04 ` Attic Hermit @ 2017-10-05 14:47 ` Hartmut Goebel 2017-10-06 5:36 ` Oleg Pykhalov 1 sibling, 1 reply; 15+ messages in thread From: Hartmut Goebel @ 2017-10-05 14:47 UTC (permalink / raw) To: help-guix Am 26.09.2017 um 20:10 schrieb Oleg Pykhalov: > Adonay Felipe Nogueira <adfeno@hyperbola.info> writes: > >> As a personal preference, I always do: >> >> # guix pull && guix package -u >> >> ... as root, and then: >> >> $ guix pull && guix package -u >> >> ... as normal user > I wrote a little script to not compile 2 times :-) What should be the use of pulling guix for both root and the user? If you symlink root's `guix` into e.g. /usr/local/bin, all users can use root's version: ln -s /var/guix/profiles/per-user/root/guix-profile/bin/guix /usr/local/bin/guix This is described in https://www.gnu.org/software/guix/manual/guix.html#Binary-Installation number 6. -- Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should I upgrade root user's guix too? 2017-10-05 14:47 ` Hartmut Goebel @ 2017-10-06 5:36 ` Oleg Pykhalov 0 siblings, 0 replies; 15+ messages in thread From: Oleg Pykhalov @ 2017-10-06 5:36 UTC (permalink / raw) To: help-guix Hello Hartmut, Hartmut Goebel <h.goebel@crazy-compilers.com> writes: > Am 26.09.2017 um 20:10 schrieb Oleg Pykhalov: >> Adonay Felipe Nogueira <adfeno@hyperbola.info> writes: >> >>> As a personal preference, I always do: >>> >>> # guix pull && guix package -u >>> >>> ... as root, and then: >>> >>> $ guix pull && guix package -u >>> >>> ... as normal user >> I wrote a little script to not compile 2 times :-) > > What should be the use of pulling guix for both root and the user? I assume it could be very useful as Ludovic mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28699 with “channels”. So your root could have stable channel, while your user could have bleeding edge channel from my understanding. > If you symlink root's `guix` into e.g. /usr/local/bin, all users can use > root's version: > > ln -s /var/guix/profiles/per-user/root/guix-profile/bin/guix > /usr/local/bin/guix > > This is described in > https://www.gnu.org/software/guix/manual/guix.html#Binary-Installation > number 6. Nice tip, thanks. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2017-10-06 5:36 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-09-22 11:08 Should I upgrade root user's guix too? Attic Hermit 2017-09-23 7:47 ` Chris Marusich 2017-09-23 8:17 ` Attic Hermit 2017-09-23 9:18 ` Chris Marusich 2017-09-23 13:05 ` Attic Hermit 2017-09-23 13:22 ` Adonay Felipe Nogueira 2017-09-24 18:01 ` Quiliro Ordonez Baca 2017-09-25 21:12 ` Chris Marusich 2017-09-26 18:10 ` Oleg Pykhalov 2017-09-27 2:04 ` Attic Hermit 2017-09-27 2:48 ` Attic Hermit 2017-09-30 0:38 ` Oleg Pykhalov 2017-09-30 3:47 ` Attic Hermit 2017-10-05 14:47 ` Hartmut Goebel 2017-10-06 5:36 ` Oleg Pykhalov
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).