From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Wingo Subject: Re: guix is the guildhall that we always wanted! Date: Fri, 17 Mar 2017 10:45:17 +0100 Message-ID: <87a88knsnm.fsf@igalia.com> References: <87zigl3wph.fsf@pobox.com> <87a88kanjq.fsf@netris.org> <87o9x0uag9.fsf@gnu.org> <162ed651-45b6-0521-7c7e-46967ef11bac@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cooTF-0000ZP-9f for guix-devel@gnu.org; Fri, 17 Mar 2017 05:46:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cooTA-0003Dc-En for guix-devel@gnu.org; Fri, 17 Mar 2017 05:46:53 -0400 Received: from pb-sasl1.pobox.com ([64.147.108.66]:57602 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cooTA-0002m6-A5 for guix-devel@gnu.org; Fri, 17 Mar 2017 05:46:48 -0400 In-Reply-To: <162ed651-45b6-0521-7c7e-46967ef11bac@gmx.net> (Florian Paul Schmidt's message of "Fri, 17 Mar 2017 10:01:40 +0100") 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: Florian Paul Schmidt Cc: guix-devel@gnu.org On Fri 17 Mar 2017 10:01, Florian Paul Schmidt writes: > On 03/16/2017 11:24 PM, Ludovic Court=C3=A8s wrote: >> I think having repos maintained elsewhere is OKish, but it=E2=80=99s tru= e that >> it requires people who maintain those repos to follow closely what=E2=80= =99s >> going on in Guix proper because we=E2=80=99re not guaranteeing API stabi= lity. > > Wouldn't taking the functional/reproducibility aspect one step further > migitate this issue? I.e. maintainers of decentralized repos just need > to have as input the precise guix version they are using? This is certainly possible. Currently the Guix revision is an implicit input to everything; a guix package "bar" may depend on "foo@2.1", but the precise built derivation of "foo" on which you depend will evolve over time as the dependencies change (glibc for example). Relying on a fixed Guix version fixes this, but at a cost of adding a new dimension of maintenance complexity that is not reducible in an automatic way at run-time. I explain. For complexity, in the Guix project itself we have one git repo with N packages; right now packages for a given revision of git, packages only depend on each other in that revision. But if you start to build systems that have packages depending on packages *at M specific revisions in Git*, you no longer have N nodes in your graph, you have N*M. That's a serious increase in maintenance cost for the system as a whole (if indeed you do decide to maintain it). However when you actually instantiate a given application (process) it is only going to depend on one libc, and one "libfoo". (I know Rust's cargo has some facility to import multiple versions of libraries. It does so by making the types that those versions work on distinct. But in Guile there's no easy facility here.) So in practice you do have to resolve the M revisions of Guix into a single revision. How do you do that in a system that depends on multiple libc versions? In many ways it is better to avoid the issue and have one system that evolves over time. When you are building an operating system as a collection of somewhat independent packages that communicate over shared standard protocols and not shared ABI, version skew is more manageable. But when building composite processes that need to agree on API and ABI internally, the problem is hard. A guildhall module needs to be able to compose with other modules and for that reason I think specifying the Guix revision is not the right thing. Just my humble opinion of course :) Andy