From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: A registry for distributed sources and binaries Date: Sun, 24 Jul 2016 22:02:04 +0200 Message-ID: <87zip67qvw.fsf@elephly.net> References: <579027b7.VHXjhpPxQC3AAmeY%pjotr.public12@email> <8760rznoh1.fsf@gnu.org> <20160722004130.GA10340@thebird.nl> <874m7hk6dz.fsf_-_@gnu.org> <20160724033027.GA20236@thebird.nl> <87shuzwqmn.fsf@netris.org> <20160724054848.GA5332@novena-choice-citizen> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRPbV-0002ZK-Hm for guix-devel@gnu.org; Sun, 24 Jul 2016 16:02:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRPbP-0003ly-JD for guix-devel@gnu.org; Sun, 24 Jul 2016 16:02:24 -0400 Received: from sender163-mail.zoho.com ([74.201.84.163]:24949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRPbP-0003lt-BT for guix-devel@gnu.org; Sun, 24 Jul 2016 16:02:19 -0400 In-reply-to: <20160724054848.GA5332@novena-choice-citizen> 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 Sender: "Guix-devel" To: Jookia <166291@gmail.com> Cc: guix-devel@gnu.org 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