From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: A registry for distributed sources and binaries Date: Sun, 24 Jul 2016 01:29:20 -0400 Message-ID: <87shuzwqmn.fsf@netris.org> References: <579027b7.VHXjhpPxQC3AAmeY%pjotr.public12@email> <8760rznoh1.fsf@gnu.org> <20160722004130.GA10340@thebird.nl> <874m7hk6dz.fsf_-_@gnu.org> <20160724033027.GA20236@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRBz5-0005K3-9M for guix-devel@gnu.org; Sun, 24 Jul 2016 01:29:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRByz-0000fz-6x for guix-devel@gnu.org; Sun, 24 Jul 2016 01:29:50 -0400 In-Reply-To: <20160724033027.GA20236@thebird.nl> (Pjotr Prins's message of "Sun, 24 Jul 2016 05:30:27 +0200") 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: Pjotr Prins Cc: guix-devel@gnu.org Pjotr Prins writes: > How about the following: > > 1. Separate from the GNU project, we create a number of registries of > online git repos without opinion (i.e., anything goes, it is up to > the authors). A registry can contain the work of multiple packages > and multiple authors. > > 2. Each repo in the registry can create package definitions online The major problem with this proposal is that, to the extent it became popular, it would drastically reduce the freedom we have to change Guix itself. We would need to start considering whether our changes might break externally maintained packages. A large proportion of our internal procedures and macros would effectively become a public API. We would no longer be able to freely make changes to the way packages are specified, or make incompatible changes to the procedures and macros used in package definitions on the client or build sides. We would be greatly constrained in our ability to make changes to the default phases in our build systems. Our core packages and most of our library packages would also effectively be part of this API. We would no longer be able to freely do things like split packages into smaller pieces or multiple outputs. Long ago, the Linux developers made a conscious decision to not support out-of-tree drivers, for much the same reasons. Many times over the years, they have made changes to their internal APIs that required corresponding changes to a large number of drivers. As a result, they have been able to keep their internal interfaces clean and free of backward-compatibility cruft. It's crucially important to the future vitality of this project that we retain our freedom to evolve the design of Guix, the way packages are specified in Guix, as well as the set of core packages. These freedoms will be drastically curtailed if we support a decentralized system of externally-managed repositories. Therefore, we must not do this. What do other people think? Mark