Pjotr Prins <pjotr.publi...@thebird.nl> 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