From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Lirzin Subject: Re: A registry for distributed sources and binaries Date: Sun, 24 Jul 2016 11:50:16 +0200 Message-ID: <8760rvxt47.fsf@gnu.org> 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRG3I-0001zy-7h for guix-devel@gnu.org; Sun, 24 Jul 2016 05:50:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRG3D-0006kJ-TR for guix-devel@gnu.org; Sun, 24 Jul 2016 05:50:27 -0400 In-Reply-To: <87shuzwqmn.fsf@netris.org> (Mark H. Weaver's message of "Sun, 24 Jul 2016 01:29:20 -0400") 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: Mark H Weaver Cc: guix-devel@gnu.org Hi, Mark H Weaver writes: > 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? I fully agree with everything you said. When acknowledging all the consequences of providing a public API for package definitions, the main goal of lowering the barrier to entry is missed because everything becomes more complex. -- Mathieu Lirzin