From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: =?utf-8?B?4oCYZ3VpeCBwdWxs4oCZ?= and external dependencies Date: Mon, 28 Nov 2016 17:58:06 -0800 Message-ID: <87wpfn2gk1.fsf@gmail.com> 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> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBXgf-0005cm-CX for guix-devel@gnu.org; Mon, 28 Nov 2016 20:58:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBXgb-0004J7-3U for guix-devel@gnu.org; Mon, 28 Nov 2016 20:58:22 -0500 In-Reply-To: <87vav7ae17.fsf_-_@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\?\= \=\?utf-8\?Q\?\=22's\?\= message of "Mon, 28 Nov 2016 15:13:08 +0100") 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org, 22629@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo`, 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 bu= ild and install > a complete =E2=80=98guix=E2=80=99 package, and to manage it pretty much l= ike 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. > 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? A system profile (like in GuixSD)? What if another user wants to run a different version of Guix? It might be nice to let them do that. 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. > 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. > 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. > 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 subs= titutes. 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. 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. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYPOCuAAoJEN1AmhXYIkadaAYP/0od3zbxya4o9kkELfpkrZbh Npj/0v46dw/h/HbCTLpu2S0ktYEG5o+eu5Ngua+bo+hKrGu7r8jcejApiSkf9oZt ayIppN4zNrJa8yp4nW2U7D6b0wWpl/vPecVJtNtU355v/ng0AGeau2dt8yRyIWoH p8JYxWiK86//cc2neNifFLD4QO+Eh7jPixjGOlZDRTyoDXTg8Va/4bHRkgxguWLd c+IhTySHCp8AfVkc4L7eNsNYWFYk9fC1wO4XSJiat5RhELAD5M1IkKpbBp5FLGnT pbvPaP4XBKOVzLWPHcQhKJyxOGKC5T0nJaHSq+FwowIAu2+IHuzTflw10fodGpVJ bkhjdILNX5KOPCa4C9nJ6PivEZtgon0iQvV8RHyNyBNqEB/m9fVHoik0tS/Xi/hv KPtOCrQOrdqlbFmzqXaeoUjb+rQIAPAVa442LgR7bGm+VQkCkkfU6wczmzrgKbWh pBFOsAvI3yjaDG4gT+8HVzcit3mRwQQ4yQsoCBGpCgfJCJtW1sX/ZrrdatCQx6bP CND2uHLBBfrK6U0s014N3CqfIBv/jtrp/4fL08sIeJodrh7oFAsPwMM6+sdO4w9B 8J190wbUYzeEEsks+7D9tE1FxzHpQV+MYjqLFNifJ4wQdpTa5Llo1iLIOV8hjBK2 7wWIyClPOZA3c766Zkmq =09gL -----END PGP SIGNATURE----- --=-=-=--