From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [RFC] A simple draft for channels Date: Fri, 19 Jan 2018 14:41:42 +0100 Message-ID: <87d1263qzt.fsf@gnu.org> References: <87bmhq6ytg.fsf@mdc-berlin.de> 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]:45361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecWvU-00011p-RR for guix-devel@gnu.org; Fri, 19 Jan 2018 08:41:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecWvR-0006TP-Lj for guix-devel@gnu.org; Fri, 19 Jan 2018 08:41:48 -0500 Received: from hera.aquilenet.fr ([185.233.100.1]:39474) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ecWvR-0006Rt-FW for guix-devel@gnu.org; Fri, 19 Jan 2018 08:41:45 -0500 In-Reply-To: <87bmhq6ytg.fsf@mdc-berlin.de> (Ricardo Wurmus's message of "Fri, 19 Jan 2018 09:24:27 +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: Ricardo Wurmus Cc: guix-devel@gnu.org Hi! Ricardo Wurmus skribis: > As a first implementation of channels I=E2=80=99d just like to have a cha= nnel > description file that records at least the following things: > > * the channel name (all lower case, no spaces) > * a URL from where package definitions can be loaded (initially, this > can be restricted to git repositories) > > Optional fields: > > * a description of the channel > > * a URL from where substitutes for the packages can be obtained (this > will be backed by =E2=80=9Cguix publish=E2=80=9D) > > * a mail address or URL to contact the maintainers of the channel, or to > view the status of the channel > > * the Guix git commit that was used when this channel was last > updated. This is useful when Guix upstream breaks the ABI or moves > packages between modules. Sounds good. > On the Guix side we=E2=80=99d need to add the =E2=80=9Cguix channel=E2=80= =9D command, which > allows for adding, removing, updating, and downgrading channels. Adding > a channel means fetching the channel description from a URL and storing > state in ~/.config/guix/channels/, and fetching the git repo it > specifies (just like what guix pull does: it=E2=80=99s a git frontend). I think what you described above is =E2=80=9Cconfig=E2=80=9D rather than = =E2=80=9Cstate.=E2=80=9D To me, =E2=80=9Cstate=E2=80=9D would be the current channel commit being us= ed and the list of previous commits that were used (akin to the Git reflog). That way, one could always roll back a =E2=80=9Cguix pull=E2=80=9D or =E2=80=9Cg= uix channel update=E2=80=9D operation. The reflog thing is a feature we can already add to =E2=80=98guix pull=E2= =80=99. I think the migration to channels can be incremental. > It also authorizes the the substitute server=E2=80=99s public key. This would require root access. > Internally, it=E2=80=99s just like GUIX_PACKAGE_PATH in that the repos ar= e used > to extend the modules that Guix uses. Unlike GUIX_PACKAGE_PATH, > however, we now have a way to record the complete state of Guix, > including any extensions: the version of Guix and all active channels > with their versions. We would also have a way to fetch substitutes from > channels without having to =E2=80=9Cglobally=E2=80=9D enable new substitu= te servers and > authorize their keys. (Is this safe? Can we have per-user extensions > to the set of public keys that are accepted?) Authorizing keys is necessarily limited to root since the store is shared among all users of the machine. I don=E2=80=99t see any way around = that (other than switching to the other model presented in Eelco=E2=80=99s thesi= s, which is to content-address derivation outputs=E2=80=94but I don=E2=80=99t = imagine us playing with that idea in the near future :-)). > Downsides: Guix has no stable ABI, so channels that are not up-to-date > will break with newer versions of Guix. Moving around packages to > different modules might break channels. That=E2=80=99s okay. It=E2=80= =99s still an > improvement over plain GUIX_PACKAGE_PATH. > > I don=E2=80=99t think it has to be more complicated than that. What do y= ou > think? I agree! One thing that=E2=80=99s still an open question is how we should treat Guix itself in that channelized world. Should Guix be a =E2=80=9Cnormal=E2=80=9D channel? It=E2=80=99s tempting t= o think of it as a regular channel; however, it=E2=80=99s definitely =E2=80=9Cspecial=E2=80=9D= in that it can update the =E2=80=98guix=E2=80=99 command, maybe guix-daemon & co., locale = data, etc. How does that affect =E2=80=98guix channel=E2=80=99? Thanks, Ludo=E2=80=99.