From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: "guix potluck", a moveable feast Date: Sat, 01 Apr 2017 19:20:25 -0700 Message-ID: <87shlrim8m.fsf@gmail.com> References: <87d1cxh5f0.fsf@igalia.com> <87o9wfenkk.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]:43795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cuV86-0007if-Gr for guix-devel@gnu.org; Sat, 01 Apr 2017 22:20:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cuV85-0003FO-OA for guix-devel@gnu.org; Sat, 01 Apr 2017 22:20:34 -0400 In-Reply-To: <87o9wfenkk.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 02 Apr 2017 01:05:15 +0200") 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, guile-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Beside, related to Chris=E2=80=99 comment, I=E2=80=99m a bit concerned ab= out versioning > in such a widely distributed repo. The package graph in Guix has zero > degrees of liberty: every package is connected to other packages; every > Guix user sees the exact same graph. > > Here, we=E2=80=99d have to be more flexible and allow potluck.scm files t= o just > say =E2=80=9Cimport guile=E2=80=9D or =E2=80=9Cimport guile@2.0=E2=80=9D;= =E2=80=9Cimport guile=E2=80=9D might provide > 2.0 on a machine running an older Guix, and it might give 2.2.9 on an > up-to-date machine. > > IOW, we=E2=80=99re no longer describing one specific graph, but instead > describing a family of graphs with some constraints. The benefits are > decentralization, but the main drawback is non-reproducibility: the > result would depend on the user machine=E2=80=99s initial state. > > To work around that, I think the server should resolve package > specifications when the potluck.scm file is submitted, and insert each > package in the Guix package graph of the moment. Does that make sense? > Maybe that=E2=80=99s what you were describing when you talk about rewriti= ng > potluck.scm files so? When you say "insert each package in the Guix package graph," do you mean, "add the package definition to the Guix source tree"? What if "the potluck" maintained a pointer to the version (i.e., the commit) of the Guix package definitions that it uses as its "base"? From=20time to time, the potluck could update its pointer to point to a more recent version of Guix's package definitions. In this way, every version of the potluck would precisely specify the dependencies of all the packages in that version of the potluck, including any transitive dependencies that ultimately come from the official Guix package definitions (as defined in the "base" version); there would be no surprising version drift. I wonder if that would work? What if someone wants to add a package definition to the Guix source tree which depends on a package that is defined in the potluck? =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAljgX+kACgkQ3UCaFdgi Rp0Ugg//ZjmzPRKy6PJd/FjexJucu/EfW8n/rVOjo73D5MWKmY0ICP3KNQir8GqC Cb4VAQbKzZRvcuOzVLdDLz159nLNf0NNMx0MnGZWUmtWXJnA+j9f2K6FDwmSjTab nhJDqLHeOlBmDQk79439PaOPS/tU/avOGpxPX9+ncVGnK2ESPa1fcr02eqY1e3US PW35/fjcpRBS527QPrKjwU/7K7MqceIUid1Igl+j4+tL+1z5v3mcjqO8LpttT2c9 Xv82XLBa+hDl+e4C8e2pHw9JdMAlrimUptnDTsD+uJBOc+HyAO9VSutFF01KUnBr L30nG2j5WRc/EkEDfQYInGECM+PnewPkhGwmq10aPyWLT4XdGY21c00ri8jn9lUb t+6yyn5R65ATF/TlYOSsKvvMfGAfnuGN3N/SBGWkyTeCYDAuptt3BANLf0q5kPdM n1OaNSRgGpIOMO51wbcu1+MNygMlgdVLecIGwEAriaEmf8EZB7Z1OqRrI3gQ6e0A jcO9ZmytqdweMVIUpM5chePSPLJDkmFD5/IkL2Ya2wWTPszipumM+7IvYd+o7be9 RuDkZ0vSZr5us8eXqdJr0HATAr/en+OLWv5xCns8OuEdS8eiKuh5L5QXHo7n6AEx zJIk7K9iWX2ppulUmbbUkj9tvuWasPNCATjWhnvQ+ROmpCRUjaU= =eOks -----END PGP SIGNATURE----- --=-=-=--