Should I upgrade root user's guix too?

Should I upgrade root user's guix too?

[Attic Hermit]

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

Re: Should I upgrade root user's guix too?

[Chris Marusich]

[-- 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 --]

Re: Should I upgrade root user's guix too?

[Attic Hermit]

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

Re: Should I upgrade root user's guix too?

[Chris Marusich]

[-- 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 --]

Re: Should I upgrade root user's guix too?

[Attic Hermit]

> 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

Re: Should I upgrade root user's guix too?

[Adonay Felipe Nogueira]

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.

Re: Should I upgrade root user's guix too?

[Quiliro Ordonez Baca]

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?

Re: Should I upgrade root user's guix too?

[Chris Marusich]

[-- 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 --]

Re: Should I upgrade root user's guix too?

[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 :-)

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

Re: Should I upgrade root user's guix too?

[Attic Hermit]

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

Re: Should I upgrade root user's guix too?

[Attic Hermit]

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

Re: Should I upgrade root user's guix too?

[Oleg Pykhalov]

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.

Re: Should I upgrade root user's guix too?

[Attic Hermit]

> 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

Re: Should I upgrade root user's guix too?

[Hartmut Goebel]

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 |

Re: Should I upgrade root user's guix too?

[Oleg Pykhalov]

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.