From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: "guix potluck", a moveable feast Date: Sun, 02 Apr 2017 11:24:40 +0200 Message-ID: <87shlrb1rb.fsf@gnu.org> References: <87d1cxh5f0.fsf@igalia.com> <87o9wfenkk.fsf@gnu.org> <87shlrim8m.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <87shlrim8m.fsf@gmail.com> (Chris Marusich's message of "Sat, 01 Apr 2017 19:20:25 -0700") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sender: "guile-devel" To: Chris Marusich Cc: Andy Wingo , guix-devel@gnu.org, guile-devel@gnu.org List-Id: guix-devel.gnu.org Chris Marusich skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Beside, related to Chris=E2=80=99 comment, I=E2=80=99m a bit concerned a= bout 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 = to 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 rewrit= ing >> 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 package= s to the graph as per GUIX_PACKAGE_PATH. > 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 th= at 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 means= we have to pay attention to version issues when the potluck is referring to packages provided by Guix. > 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. Ludo=E2=80=99.