Re: "guix potluck", a moveable feast

[Chris Marusich <cmmarusich@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]

ludo@gnu.org (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
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’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.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]