[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "guix potluck", a moveable feast

From: Chris Marusich
Subject: Re: "guix potluck", a moveable feast
Date: Mon, 03 Apr 2017 19:20:46 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

address@hidden (Ludovic Courtès) 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’s what you were describing when you talk about rewriting
>>> 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’s a separate source tree.  I mean add the potluck packages 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’s 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’s 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.

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

>> 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’t 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.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]