From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: =?utf-8?B?4oCYZ3VpeCBwdWxs4oCZ?= and external dependencies Date: Tue, 29 Nov 2016 15:54:42 +0100 Message-ID: <87wpfm49ql.fsf@gnu.org> References: <87poma53yi.fsf@gnu.org> <87oa13qimp.fsf@gnu.org> <20161126044257.GA15256@jasmine> <87zikmb7ix.fsf@member.fsf.org> <87k2bok1zm.fsf@gnu.org> <20161128100636.GB2509@macbook42.flashner.co.il> <87vav7ae17.fsf_-_@gnu.org> <87wpfn2gk1.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBjo7-0006kz-Pb for guix-devel@gnu.org; Tue, 29 Nov 2016 09:54:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBjo6-0003yI-Ny for guix-devel@gnu.org; Tue, 29 Nov 2016 09:54:55 -0500 In-Reply-To: <87wpfn2gk1.fsf@gmail.com> (Chris Marusich's message of "Mon, 28 Nov 2016 17:58:06 -0800") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel@gnu.org, 22629@debbugs.gnu.org Hello, Chris Marusich skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> So I think what we need to do is for =E2=80=9Cguix pull-ng=E2=80=9D to b= uild and install >> a complete =E2=80=98guix=E2=80=99 package, and to manage it pretty much = like other >> packages is managed,=20 > > 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 =E2=80=98package=E2=80=99, on build system implementations, a= nd so on. We could have guix-sans-daemon though, if that helps (which I suspect is not the case). >> except not in the user=E2=80=99s main profile (because that could lead to >> undesirable behavior,=20 > > If we don't store Guix in the user's main profile, where would it go? In =E2=80=9Csome sort of a profile=E2=80=9D in ~/.config/guix/latest or sim= ilar. > 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=E2=80=99s the manifest format change issue I mentioned, or the inabil= ity to roll back if you install a broken Guix. >> where upgrading Guix creates a new generation,=20 > > 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=E2=80=99m suggesting that upgrading Guix creates a new generation (so we = agree here), just not in the user=E2=80=99s 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=E2=80=99re 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=E2=80=99s 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=E2=80=99t want to do that on each =E2= =80=98guix pull=E2=80=99 >> invocation (esp. with Guile 2.2=E2=80=99s compilation times.) >> >> So we may have to provide substitutes of Guix itself, and arrange so >> that =E2=80=98guix pull=E2=80=99 pulls up to a tag for which we have sub= stitutes. > > 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 =E2=80=98guix pull=E2=80=99 at an arbitrary po= int 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=E2=80=99.