guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A registry for distributed sources and binaries


From: Tobias Geerinckx-Rice
Subject: Re: A registry for distributed sources and binaries
Date: Sun, 24 Jul 2016 08:28:30 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

Mark,

On 24/07/2016 7:29, Mark H Weaver wrote:
> 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.

As well they should. As well should Guix. If anything, I consider
Linux's misguided ABI stability fetish to be an embarrassment, and hope
Guix never makes the same mistake, binary or not. 1.0 or not.

> 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.

Absolutely.

> These freedoms will be drastically curtailed...

...if Guix chooses to impose misguided stability guarantees upon itself.

> if we support a decentralized system of externally-managed 
> repositories.

No. Break them.

If you're running an external Guix repository and don't bother to follow
the main development branch(es) with some attention, your users deserve
to get regular breakage warnings as a subtle hint that maybe they
shouldn't be trusting you with their software.

...provocation being the genesis of this thread and all :-)

> Therefore, we must not do this.

There seem to be two different meanings of ‘support’ at play here:
   - adding decentralised repository support to Guix so it can at least
     be done in a clean user-friendly way, which I think is excellent
vs.
   - promising some kind of API stability to those repositories, which
     I think is terrible.

It is quite possible that you can't have one without the other, or that
there's no sane way to coordinate API updates and their distribution to
users, or that it would make reproducibility a nightmare, or that it
would make Guix look bad when $randomthirdpartyrepository breaks. I
haven't sat down to sketch out all corner cases; I just write things on
the Internet.

I'm just not convinced by ‘X is bad, so we mustn't do Y’ until its
absolutely certain X requires Y.

> What do other people think?

More voices would be nice indeed! This thread has clarified several
interesting viewpoints.

Kind regards,

T G-R



reply via email to

[Prev in Thread] Current Thread [Next in Thread]