Re: A registry for distributed sources and binaries

[Ricardo Wurmus <rekado@elephly.net>]

Jookia <166291@gmail.com> writes:

> I think the clearest system is a way to have multiple guixes installed at once.
> Other package managers need not do this, but as long as the daemon compatiblity
> is kept it should be fine. There could be a guix-jookia, guix-nonfree for those
> that really want to run it on their nonfree systems. These would have their own
> internal system with maximum freedom for experimentation. Getting users to
> install these systems would be the hard part.

Maybe I’m missing something, but this seems to work for me at the MDC.
Before the mercurial downloader was merged, for example, I just added it
to the repository that was referred to in GUIX_PACKAGE_PATH.   It sat
there for a while until I had cleaned it up enough to submit it for
review as a patch.

Users can already do all these things with GUIX_PACKAGE_PATH, in
particular they can

* install non-free stuff
* define packages with procedures that are not in Guix upstream

Anyone can use “guix publish” to *trivially* share binaries on demand
with people who might want them.

This mechanism is *already* supported by Guix.

Although I agree with Mark that Guix should not freeze its API, I don’t
consider this a problem in practice.

For the MDC I have a separate repository with packages and supporting
infrastructure that we have been using since at least March 2015.  We
never had any problems with API stability.  One package’s inputs had to
be changed when a package in Guix upstream was renamed.

For anyone going through the effort to distribute an additional set of
packages and features it really should not be a problem to make these
minor adjustments once in a long while.

~~ Ricardo