From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tobias Geerinckx-Rice Subject: Re: A registry for distributed sources and binaries Date: Sun, 24 Jul 2016 08:28:30 +0200 Message-ID: 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; charset=windows-1252 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRCub-0006vn-3o for guix-devel@gnu.org; Sun, 24 Jul 2016 02:29:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRCuZ-0000fd-3s for guix-devel@gnu.org; Sun, 24 Jul 2016 02:29:16 -0400 Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:45072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRCuY-0000fZ-Ts for guix-devel@gnu.org; Sun, 24 Jul 2016 02:29:15 -0400 In-Reply-To: <87shuzwqmn.fsf@netris.org> 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 , Pjotr Prins Cc: guix-devel@gnu.org 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