From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: "guix potluck", a moveable feast Date: Mon, 03 Apr 2017 19:20:46 -0700 Message-ID: <878tngvrpd.fsf@gmail.com> References: <87d1cxh5f0.fsf@igalia.com> <87o9wfenkk.fsf@gnu.org> <87shlrim8m.fsf@gmail.com> <87shlrb1rb.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]:59962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cvE5X-0006iw-GH for guix-devel@gnu.org; Mon, 03 Apr 2017 22:20:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cvE5W-0004Lz-IJ for guix-devel@gnu.org; Mon, 03 Apr 2017 22:20:55 -0400 In-Reply-To: <87shlrb1rb.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 02 Apr 2017 11:24:40 +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: >>> 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 rewri= ting >>> 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"? > > No no, it=E2=80=99s a separate source tree. I mean add the potluck packa= ges to > the graph as per GUIX_PACKAGE_PATH. OK, that makes sense. >> 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 time 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? > > Then there=E2=80=99s the problem that Mark pointed out earlier, which is = that it > would force users to use a specific set of dependencies, possibly not > current, when using the potluck. > > I think it=E2=80=99s nicer if both repos are decoupled, although that mea= ns we > have to pay attention to version issues when the potluck is referring to > packages provided by Guix. I've reconsidered, and I think what I suggested is probably not a good idea. The result of pinning a package's dependencies to specific versions tends to be that it becomes harder to update those dependencies. And when finally somebody does manually update those dependencies (which is not often), it causes breakage which is difficult to fix, but which would have been easier to fix if it had been noticed sooner. So, decoupling in the way you suggest is probably better. Reproducible builds can still be achieved by specifying the precise version (i.e., commit) of the potluck and also of the Guix package definitions. >> 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? > > I guess we wouldn=E2=80=99t allow that in the Guix repo proper. That makes sense. If a package can be imported wholesale into the collection of Guix package definitions (instead of the potluck), then that seems like the right thing to do. Situations where I can imagine that not being possible are, for example, where the software defined by a potluck package is not available under a free license. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAljjAv4ACgkQ3UCaFdgi Rp3iKw//bWIxPkHF2QgyA4jP2vVHgfkcU6ym02yqDH86pnPhnoLxt8dINU7J89Ka P8+IZY4/CRjtX3z9smXu2PKHkfwpDVzqLVY2kqweS0zUiq+3Iu6jgkodtnuVPbOt geVzjqib0KoMCsUXBJWaakik/WfkMvMDN/5auW35KDnBbjaICyBQk6zSe/Q307c0 PH2b0VhHaHjWdiUgfZCStqT0m8IHtHccz8LKkugMItxOkGd0nJy3ra+7KMy+rrC+ J1YMe/hPM/W8moz0ASt8gP3mf3hL96nvfEZs+l0cGbrPfeHpHmDFX5XILVL2kn8B aZm1QTD1842oB/d8Pkx3bAIdkbSkNbEgG68E51O3vc8oKOo74OhHXin8GJ1HwKPH eBKwMsceQJo20DPsyBDZmLQgk4G3bhBEOLAYE+cXvbTZNl91xUkjH2LzbdK0ALAt OcdQAi/rUvYzUMRC3Nbzkro1BkXFmm9FqHqxV4aW4UIX9RYj5jxO7Au+4Pd5vFlf 3rODjIcuoYchzbC+mQrM5x8XH3X/ZUbYGPb6YmrFY0lTq2/EcgxWUgsYQJm5Q4W1 UK0xron6v3D0uq4Qmm8y1GV4rSNMcnCBbMxVJkRDas59P7xxEUxo4znyNoop2IC2 rYUN6QQVT59440tqRadQLBvKTzhoGhj5xa0zT2/4c8VQjLsyVfo= =nMoU -----END PGP SIGNATURE----- --=-=-=--