guix pull

[ludo@gnu.org (Ludovic Courtès)]

Andreas Enge <andreas@enge.fr> skribis:

> On Sun, Apr 12, 2015 at 03:38:58PM +0200, Ludovic Courtès wrote:
>> Anyway, I recommend against using repeated “make install”, one reason
>> being that there can be leftovers if you don’t run “make uninstall”
>> beforehand.
>
> It seems to be the good way of working in my "multi-user" setting. Why
> should every user handle his own copy of guix? For instance, the daemon
> needs to be installed in a system location to be started by the init system.
> Anyway, "make install" needs to work.

Of course it has to work, no argument here.  :-)

However, it is stateful, which makes it easier to get into troubles (for
instance because a stale .scm file remains available, so ‘guix package
-A’ would show its contents, or because of obscure timestamp issues on
existing files, particularly if one tries
“make install INSTALL='install -C'”, etc.)

>> “guix pull” is meant to be a handy way to deal with updates.
>
> Does this not interfere badly with git? I am running "make install" from my
> latest stable master git branch, so that every user on the system has a recent
> stable guix, with "stable" in the sense of a rolling release, not the latest
> official relase.

Right, the model with “guix pull” is that each user is responsible for
updating their local Guix.  From the sysadmin’s viewpoint, this is bad,
because each user could have their own thing, and some could still be
installing old packages with security issues.  From the user’s
viewpoint, it’s total freedom.

Perhaps “guix pull” could honor sysadmin-handled updates, for those
cases where users do not want to run “guix pull” by themselves.  Say,
‘guix’ would look for ~/.config/guix/latest first, and then
/var/guix/latest.  Thoughts?

> Then I use "./pre-inst-env" from my private branch in which I am
> developing new packages.

Sure.

Thanks,
Ludo’.