Re: A registry for distributed sources and binaries

[Mathieu Lirzin <mthl@gnu.org>]

Hi,

Mark H Weaver <mhw@netris.org> writes:

> Pjotr Prins <pjotr.public12@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?

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