GNU bug report logs - #22629
Towards a new 'guix pull'

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: Chris Marusich <cmmarusich <at> gmail.com>
Cc: guix-devel <at> gnu.org, 22629 <at> debbugs.gnu.org, Efraim Flashner <efraim <at> flashner.co.il>
Subject: bug#22629: ‘guix pull’ and external dependencies
Date: Tue, 29 Nov 2016 15:54:42 +0100

Hello,

Chris Marusich <cmmarusich <at> gmail.com> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>
>> So I think what we need to do is for “guix pull-ng” to build and install
>> a complete ‘guix’ package, and to manage it pretty much like other
>> packages is managed, 
>
> I think that's very reasonable.  It seems more intuitive than the
> current way 'guix pull' works.  I suspect that managing the installed
> version of Guix via the same Guix mechanisms that we use to manage any
> other package might be the best, most intuitive solution.
>
> Would it simplify the problem if we packaged the "Guix client stuff",
> the "Guix daemon stuff", and maybe the "Guix package definition stuff"
> separately?  Then a user could just install the "Guix client stuff"
> package if she wanted to upgrade the Guix client tools, or the "Guix
> package definition stuff" package if she wanted to get the latest
> package definitions.

It would be bad to separate package definitions from the rest because
they are very much intertwined: package definitions depend on the
definition of ‘package’, on build system implementations, and so on.

We could have guix-sans-daemon though, if that helps (which I suspect is
not the case).

>> except not in the user’s main profile (because that could lead to
>> undesirable behavior, 
>
> If we don't store Guix in the user's main profile, where would it go?

In “some sort of a profile” in ~/.config/guix/latest or similar.

> It's not clear to me why it's riskier to store Guix in a profile rather
> than outside the profile (but still in the store via the
> $HOME/.config/guix/latest symlink), which is what 'guix pull' does now.
> You seem to think it's riskier; I'm curious to know more about why.

There’s the manifest format change issue I mentioned, or the inability
to roll back if you install a broken Guix.

>> where upgrading Guix creates a new generation, 
>
> Why should upgrading Guix NOT create a new generation?  I thought that a
> new profile generation would be created any time you upgrade a package,
> and I thought that was a good thing because it facilitates easy,
> transactional roll-back.  Perhaps I'm missing something.

I’m suggesting that upgrading Guix creates a new generation (so we agree
here), just not in the user’s profile.

>> or, in theory, unrecoverable problems, where you cannot roll back
>> because previous generations use an old Guix that does not understand
>> the new manifest format.)
>
> Why would a change in manifest format be unrecoverable?  It looks like
> each profile generation contains a manifest file.  Assuming that the new
> Guix functions well enough to perform roll back, couldn't we just roll
> back to the previous profile generation, where we would have both (1)
> the old profile's manifest file, and (2) the previous Guix, which
> understands that format?  Since rolling back a profile is basically just
> a symlink flip, I think the new Guix could probably do that even if it
> didn't understand the old manifest format.

Yeah, I think you’re right.  :-)

In general, I think my concern is more that we cannot promise that
downgrading Guix will work, considering the potential for on-disk format
changes.  It’s a bit theoretical, but not entirely sci-fi either.

>> The difficulty is that ./configure && make && make install in Guix takes
>> some time, and we probably wouldn’t want to do that on each ‘guix pull’
>> invocation (esp. with Guile 2.2’s compilation times.)
>>
>> So we may have to provide substitutes of Guix itself, and arrange so
>> that ‘guix pull’ pulls up to a tag for which we have substitutes.
>
> What if we had a special package version of Guix (e.g., "v0.11.0") which
> we kept up to date via some mechanism?  Maybe something as simple as a
> Git hook could help increase the likelihood of that version being
> substitutable.  For example, we could have a Git hook that prevents
> someone from checking in a change if the latest Git tag does not
> correspond to a Guix package version.  Maybe we can do better.

Right, we could do something like that.  There are still non-zero
chances that someone running ‘guix pull’ at an arbitrary point in time
will have to build locally, which is not great.

> I actually think it would be a good thing if we can run "guix pull"
> without substitutes available.  But it should use a substitute by
> default, and "build from source" should be a fallback mechanism that the
> user has to explicitly request, just like when installing new packages.
> That would help avoid unexpectedly long "guix pull" invocations.

Yes, using substitutes or falling back to source builds is always the
default.

Thanks for your feedback!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.