From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: [Orchestration][RFC] A simple draft for channels Date: Tue, 20 Mar 2018 11:41:33 +0100 Message-ID: <87r2ofc9lu.fsf@elephly.net> References: <87bmhq6ytg.fsf@mdc-berlin.de> <87shar5wp8.fsf@gmail.com> <20180319120400.GA13807@thebird.nl> <20180320070224.GA20987@thebird.nl> 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]:45068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyExO-0007AH-1g for guix-devel@gnu.org; Tue, 20 Mar 2018 06:57:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eyExJ-0002Fl-3K for guix-devel@gnu.org; Tue, 20 Mar 2018 06:57:30 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21070) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eyExI-0002EG-Q5 for guix-devel@gnu.org; Tue, 20 Mar 2018 06:57:25 -0400 In-reply-to: <20180320070224.GA20987@thebird.nl> 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: Pjotr Prins Cc: guix-devel@gnu.org, Ricardo Wurmus Pjotr Prins writes: > On Mon, Mar 19, 2018 at 01:04:00PM +0100, Pjotr Prins wrote: >> Maybe we should start thinking that a channel is simply an >> architecture dependent Guix 'pack' of substitutes that includes the >> pre-built Guix git repo. When deployed in a container we can inject >> the keys. When this works we can design a pack repository, making the >> channels searchable. > > Continuing my line of thought: a binary channel in my mind is now a > compiled Guix package tree with Guix and possible adaptations (say a > special package for Ruby). In other words, a special (timed) version > of Guix sitting in /gnu/store/*named-guix-channel/bin/guix. What you describe is essentially =E2=80=9Cguix pull=E2=80=9D. =E2=80=9Cgui= x pull=E2=80=9D can already use a different branch or a different repository. It has at least two problems in this context: 1) it only keeps a link to the =E2=80=9Clatest=E2=80=9D Guix. There is no = way to declare the use of a different variant of Guix. 2) it builds everything from source (Ludo=E2=80=99s branch for splitting th= e target of =E2=80=9Cguix pull=E2=80=9D into several derivations addresses= this) Maybe we should address the first problem next and allow for not only the latest Guix version to be retained. This is not quite the same as a regular profile, because these different variants of Guix surely would provide colliding files. The guix command would need to be changed to pick =E2=80=9Clatest=E2=80=9D = by default, but use a different variant if specified. The workflow would be something like that: # fetch Guix from somewhere and record as =E2=80=9Cfoobar=E2=80=9D guix pull --url=3Dhttps://somewhere foobar # use that variant of Guix guix --variant=3Dfoobar build hello I don=E2=80=99t think this should be the only mechanism through which peopl= e can provide channels. I wouldn=E2=80=99t want to have to essentially fork Guix= . For a user this is a problem, too, because channels would no longer be composable (today I can compose multiple package collections with GUIX_PACKAGE_PATH). -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net