guix pull

guix pull

[Federico Beffa]

Hi,

I've noticed that if I run "guix pull" from a directory where I do not
have write permission I get an error:

guix pull: error: mkstemp!: Permission denied

Maybe it should be created in /tmp?

Regards,
Fede

Re: guix pull

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> I've noticed that if I run "guix pull" from a directory where I do not
> have write permission I get an error:
>
> guix pull: error: mkstemp!: Permission denied
>
> Maybe it should be created in /tmp?

Indeed, this is a bug.  Should be fixed now, thanks.

Ludo’.

Re: guix pull

[Federico Beffa]

On Wed, Sep 17, 2014 at 7:19 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> Federico Beffa <beffa@ieee.org> skribis:
>
>> I've noticed that if I run "guix pull" from a directory where I do not
>> have write permission I get an error:
>>
>> guix pull: error: mkstemp!: Permission denied
>>
>> Maybe it should be created in /tmp?
>
> Indeed, this is a bug.  Should be fixed now, thanks.


I believe to have found another problem after doing a "guix pull": In
the directory $HOME/.config/guix/latest/guix there is a file called
"config.scm.in". Shouldn't this file be processed and output
"config.scm"?

Regards,
Fede

Re: guix pull

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> I believe to have found another problem after doing a "guix pull": In
> the directory $HOME/.config/guix/latest/guix there is a file called
> "config.scm.in". Shouldn't this file be processed and output
> "config.scm"?

No, it’s on purpose: the goal is to keep using the already-installed
(guix config), which contains the right file names etc.

Ludo’.

Re: guix pull

[Federico Beffa]

> No, it’s on purpose: the goal is to keep using the already-installed
> (guix config), which contains the right file names etc.

Got it. Finally I see how "guix pull" works and why importing modules
only from $HOME/.config/guix/latest/ in the REPL is not enough... :-)

Thanks,
Fede

guix pull

[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’.