From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2@gmail.com Subject: Re: [RFC] A simple draft for channels Date: Tue, 23 Jan 2018 11:03:09 -0500 Message-ID: <86fu6wh8aq.fsf@gmail.com> References: <87bmhq6ytg.fsf@mdc-berlin.de> <87d1263qzt.fsf@gnu.org> 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]:42604) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ee12d-0003vQ-4t for guix-devel@gnu.org; Tue, 23 Jan 2018 11:03:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ee12X-0008DY-4v for guix-devel@gnu.org; Tue, 23 Jan 2018 11:03:19 -0500 In-Reply-To: <87d1263qzt.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Fri, 19 Jan 2018 14:41:42 +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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org, Ricardo Wurmus On 01/19/2018 at 14:41 Ludovic Court=C3=A8s writes: > Hi! > > Ricardo Wurmus skribis: > >> As a first implementation of channels I=E2=80=99d just like to have a ch= annel >> 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 = used 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= =9Cguix 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 a= re 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 substit= ute 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 aroun= d that > (other than switching to the other model presented in Eelco=E2=80=99s the= sis, > which is to content-address derivation outputs=E2=80=94but I don=E2=80=99= t 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 = you >> think? > > I agree! > > One thing that=E2=80=99s still an open question is how we should treat Gu= ix > itself in that channelized world. > > Should Guix be a =E2=80=9Cnormal=E2=80=9D channel? It=E2=80=99s tempting= to 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., local= e data, etc. > How does that affect =E2=80=98guix channel=E2=80=99? ISTM this design allows channels to inject non-free &/or non-safe components into other user's Guix systems. Is that true? If so, how will it impact the Guix promise of software freedom/safety? WDYT? - George