From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jelle Licht Subject: Re: [RFC] A simple draft for channels Date: Fri, 19 Jan 2018 09:55:45 +0100 Message-ID: References: <87bmhq6ytg.fsf@mdc-berlin.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f40304356f8806e5c905631d3f1b" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecSSo-00031w-Bl for guix-devel@gnu.org; Fri, 19 Jan 2018 03:55:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecSSm-0002Cn-LH for guix-devel@gnu.org; Fri, 19 Jan 2018 03:55:54 -0500 Received: from mail.fsfe.org ([2001:aa8:ffed::3:102]:40169) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ecSSm-0002B7-8Q for guix-devel@gnu.org; Fri, 19 Jan 2018 03:55:52 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.fsfe.org (Postfix) with ESMTP id 022C163BB02 for ; Fri, 19 Jan 2018 09:55:50 +0100 (CET) Received: from mail.fsfe.org ([127.0.0.1]) by localhost (cavendish.fsfeurope.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9dfv29pY9bR for ; Fri, 19 Jan 2018 09:55:49 +0100 (CET) Received: by mail-ua0-f175.google.com with SMTP id t6so619248ual.7 for ; Fri, 19 Jan 2018 00:55:49 -0800 (PST) In-Reply-To: <87bmhq6ytg.fsf@mdc-berlin.de> 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 --f40304356f8806e5c905631d3f1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-01-19 9:24 GMT+01:00 Ricardo Wurmus : > Hi Guix, > > I=E2=80=99d like to retire GUIX_PACKAGE_PATH as the main way to get third= -party > packages, because we can=E2=80=99t really keep track of packages that wer= e added > or redefined in this way. I want to replace it with slightly more > formal =E2=80=9Cchannels=E2=80=9D. > > 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. > > 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). = It also > authorizes the the substitute server=E2=80=99s public key. > > 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?) > > I am not sure, but I think we need to be able to ensure that these 'new' substitute servers will only be used to get substitutes for the derivations in that specific channel. I am not sure how easy it will be to make sure this will be the case, but I guess we do not want to give any user-defined the possibility to 'overwrite' substitutes for existing derivations from system-trusted substitute servers. 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. > > We might be able to mitigate this by using by using Semantic Versioning [= 1] on a best-effort basis. Perhaps (some) changes to the abi could even be picked up and warned about by a tool not unlike the one used to generate the package listings for new releases. I am thinking of things like: - A package was renamed (so the previous named version no longer exists) - A package was moved > I don=E2=80=99t think it has to be more complicated than that. What do y= ou > think? > > -- > Ricardo > > In general, I like it and would love to play around with this soon. - Jelle [1]: https://semver.org/ --f40304356f8806e5c905631d3f1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018-01-19 9:24 GMT+01:00 Ricardo Wurmus <ricardo.wurmus@m= dc-berlin.de>:
Hi Guix,

I=E2=80=99d like to retire GUIX_PACKAGE_PATH as the main way to get third-p= arty
packages, because we can=E2=80=99t really keep track of packages that were = added
or redefined in this way.=C2=A0 I want to replace it with slightly more
formal =E2=80=9Cchannels=E2=80=9D.

As a first implementation of channels I=E2=80=99d just like to have a chann= el
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
=C2=A0 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
=C2=A0 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 =C2=A0 view the status of the channel

* the Guix git commit that was used when this channel was last
=C2=A0 updated.=C2=A0 This is useful when Guix upstream breaks the ABI or m= oves
=C2=A0 packages between modules.

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.=C2=A0 Addi= ng
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).=C2= =A0 It also
authorizes the the substitute server=E2=80=99s public key.

Internally, it=E2=80=99s just like GUIX_PACKAGE_PATH in that the repos are = used
to extend the modules that Guix uses.=C2=A0 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.=C2=A0 We would also have a way to fetch substitutes fr= om
channels without having to =E2=80=9Cglobally=E2=80=9D enable new substitute= servers and=C2=A0
authorize their keys.
[...]
(Is this safe?=C2=A0 Can we have per-user = extensions
to the set of public keys that are accepted?)

I am not sure, but I think we need to be able to ensu= re that these 'new' substitute servers
will only be used = to get substitutes for the derivations in that specific channel.
=

I am not sure how easy it will be to make sure this wil= l be the case, but I guess we do not
want to give any user-define= d the possibility to 'overwrite' substitutes for existing derivatio= ns
from system-trusted substitute servers.

Downsides: Guix has no stable ABI, so channels that are not up-to-date
will break with newer versions of Guix.=C2=A0 Moving around packages to
different modules might break channels.=C2=A0 That=E2=80=99s okay.=C2=A0 It= =E2=80=99s still an
improvement over plain GUIX_PACKAGE_PATH.

We might be able to mitigate this by using by using S= emantic Versioning [1]
on a best-effort basis. Perhaps (some) cha= nges to the abi could even be picked up and warned
about by a too= l not unlike the one used to generate the package listings for new releases= . I am
thinking of things like:
- A package was renamed= (so the previous named version no longer exists)
- A package was= moved

=C2=A0
I don=E2=80=99t think it has to be more complicated than that.=C2=A0 What d= o you
think?

--
Ricardo

In general, I like it and would love to play around w= ith this soon.

- Jelle

[1]: https://semver.org/
=C2=A0

--f40304356f8806e5c905631d3f1b--