From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Chris Marusich Newsgroups: gmane.comp.gnu.guix.devel,gmane.lisp.guile.devel 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1491272482 5072 195.159.176.226 (4 Apr 2017 02:21:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Apr 2017 02:21:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: guix-devel@gnu.org, guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Tue Apr 04 04:21:18 2017 Return-path: Envelope-to: gcggd-guix-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvE5m-00009r-9f for gcggd-guix-devel@m.gmane.org; Tue, 04 Apr 2017 04:21:10 +0200 Original-Received: from localhost ([::1]:33670 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cvE5s-0006jO-6q for gcggd-guix-devel@m.gmane.org; Mon, 03 Apr 2017 22:21:16 -0400 Original-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 Original-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 Original-Received: from mail-pg0-x242.google.com ([2607:f8b0:400e:c05::242]:34497) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cvE5T-0004HE-Vh; Mon, 03 Apr 2017 22:20:52 -0400 Original-Received: by mail-pg0-x242.google.com with SMTP id o123so33685749pga.1; Mon, 03 Apr 2017 19:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=XuraMZdajiTDlQArv7hyKD/Vrfcy+4rgvTphkv/pxRg=; b=vRyuMS78CuZKmVCnXhnyqk1H1rkUigckwg0Ui4u6FF6hWESH5u3ngPI6Z1jsiq2tk2 89+PeoZgUJ6A12knfA8pkWrVZbxFZKrNJx0BNakW3gFbdVzdkEFplIJppvcrKvhF2gu0 tuMyGnYCBhb+Lb+BQavV4X1R7rx4WQNUUqYyRy1QbRIiZvQTtdyUZA3y+bL9M0hR1v0h lGl+A8ozMb2yz0MA32HEM+Du2DMcZjGlMF/ilNHuaHmX9Q6vhNIaZPD2b5nDoZ28m+HC eM/FzUHcbcFyoNadVF0NBS5m5+2SR0u0TVxvoGRqSklsdE10bvE8/zmdQHRZFW9t3/l1 N13g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=XuraMZdajiTDlQArv7hyKD/Vrfcy+4rgvTphkv/pxRg=; b=udlpPnUOxH9fCVrWygWu4HPcTOZHfAe95sg0gmaZwS68s4fqgclupmllScbMoEBGwN PR5JvlrO54Ws75PboH23ImFNxKOVrWLNb3ADRyS169wy4JcqRb2LVvRTJH8Z6TnYiK/6 +CzpU2V26PixtdfN2LzDuIcQzXOkjiWu+ljVDW9ALKLt6hoA06l8IEb5sYP7XwZNBF1K s+by33Q4JFztVUBPo8MMCUrjyeuESfx/HSHu2trwYeLZwsknveysovWyuyJoUqEOswvA oUVZuaE+wOe5eUR0QgHnQCy5bunee2gJrBn57VweRCyepBGAtWpNXsc6ZA7BuykwApZn t+EA== X-Gm-Message-State: AFeK/H1x2MQzNBHzQKEuaamnoEkMm9vK2VGPyTmcHuqM2iT//dFhFF+uk8pEdC4FBOBeHg== X-Received: by 10.99.96.2 with SMTP id u2mr13189018pgb.96.1491272450716; Mon, 03 Apr 2017 19:20:50 -0700 (PDT) Original-Received: from garuda ([2601:602:9d02:4725:4e0f:6eff:fef6:70b9]) by smtp.gmail.com with ESMTPSA id 80sm28111488pfh.110.2017.04.03.19.20.49 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 03 Apr 2017 19:20:49 -0700 (PDT) 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") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400e:c05::242 X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list 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 Original-Sender: "Guix-devel" Xref: news.gmane.org gmane.comp.gnu.guix.devel:36791 gmane.lisp.guile.devel:19095 Archived-At: --=-=-= 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----- --=-=-=--