From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: [RFC] A simple draft for channels Date: Sat, 27 Jan 2018 04:10:27 -0800 Message-ID: <87shar5wp8.fsf@gmail.com> References: <87bmhq6ytg.fsf@mdc-berlin.de> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36100) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1efPJc-0002Lz-Oa for guix-devel@gnu.org; Sat, 27 Jan 2018 07:10:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1efPJb-0001bH-D3 for guix-devel@gnu.org; Sat, 27 Jan 2018 07:10:36 -0500 Received: from mail-pl0-x229.google.com ([2607:f8b0:400e:c01::229]:33258) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1efPJb-0001b4-4B for guix-devel@gnu.org; Sat, 27 Jan 2018 07:10:35 -0500 Received: by mail-pl0-x229.google.com with SMTP id t4so620382plo.0 for ; Sat, 27 Jan 2018 04:10:35 -0800 (PST) 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 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ricardo, This is a great start - I'm excited to playing with a prototype! Ricardo Wurmus writes: > 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) Should a channel have to declare its own version? Is this even necessary/useful, or will this be taken care of in some other way, for example by hashing the fetched copy of the channel's package definitions? > * a URL from where substitutes for the packages can be obtained (this > will be backed by =E2=80=9Cguix publish=E2=80=9D) Do you intend to couple a channel with its substitute URL? Since this is optional, it doesn't sound that way to me, but I just want to double check. Even if a channel chooses to provide its own substitutes, I think that in general a substitute for a package should be able to come from any authorized substitute server, not just the one declared by the channel. They should be decoupled. > * 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. It sounds like you intend for HUMANS to use this information (when present) in a purely ADVISORY fashion, like this: if the version of the user's installed Guix matches (or is close) the one specified here, then the channel's package definitions will (or are likely to) work correctly; otherwise, all bets are off. Is that right? What do you mean by "when this channel was last updated"? I can think of at least two interpretations: when the package definitions change, and when the substitutes change (because the channel owner built them using a different version of Guix). To maximize this information's usefulness, we should be clear about what it means. > 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. How are channels created? In other words, how will one prepare all the things that must be present at the channel URL? Will there be a command for this? > Adding a channel means fetching the channel description from a URL Will there be any restrictions on the relationship between this URL and the URL from where the channel's package definitions can be loaded? > 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). As an administrator, how will I add a channel system-wide, for all users? Will the method differ for GuixSD and foreign distros? > It also authorizes the the substitute server=E2=80=99s public key. Please correct me if I'm wrong, but my understanding is that for security reasons, we must not let an unprivileged user authorize a substitute server's public key. If the intensional model were implemented, this might be different, but since we currently use the extensional model, we must not allow it, since those substitutes will be shared by all users. To allow an unprivileged user to authorize a substitute server's public key would be to allow her to make a trust decision on behalf of all users of the system. Additional questions follow: Do you intend for this initial design to be orthogonal to the improvements for "guix pull" that have been discussed elsewhere (e.g., bug 22629)? What is the intended behavior when a channel defines a package with the same name as a "core" Guix package or a package from another channel? (Will we use some kind of prioritization or namespacing to avoid this?) For creation, deletion, upgrading, and downgrading of channels, what sort of mechanism do we plan to use? Will it be similar to profiles (e.g., flip a symlink)? Will the channel's package definitions be stored in the Guix store? How will this differ, and how will this be similar, to Nix's channel mechanism? Nix has had "channels" for a long time, so if we can copy any good ideas or techniques from there, we should. I haven't personally reviewed Nix's channel implementation in detail, so I'm not really sure how your proposal is different or similar. Thank you for getting the ball rolling on this! =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlpsbDMACgkQ3UCaFdgi Rp27cRAArn/2dekWOmKhdQyU9H6tnY/GWTdlVr+/1BWMuBpR/Epr6UHBzvh6ZSL6 y+bniat6MS+or7rfRfIC6Vmc40rK5j1jsNQ+oKAiAs4uJ48dWgQO14XYShi6DBNK PvXX7yUbvuydFPycLj62PwuBo8hnQs7k4ujKoZfmSIIHioRSfN2oU+B6oX+GqSZI 1Lsx3/rQkBHAgSMQ9hKvLCwhgAet7K8plCBOjzXQKNpVNyu51fEIZ4RSceUxNP66 7nYtzR7o1YEQBrW00wYShw0biDVT4zvkffTOxwD/ab1iwrCdh2lTAMf9aDvPhgv2 7Prlmqmwbp86aTL5igB88YXmrYIUG4KlRqNUbMp47UMkLETshDrTJ0x6JCp7LlTK SckEBz/5tfjoLSJDuRv/hAi3NsYkzOhX6ouieaN2wxphHNFqI6azb/84s/eMl5W+ EhMAkHpGQtUzAnPcdCVronajxmm8tUbelol19zjdfP4YJ/ZAZd4yKydTU9ufUZWz +Xkk1YZBz0jarQ29xDHg5vWtBfxYl9RHnOyO4YNFBlVOQ8gIBejEoJihKaUB0vU1 QVjYi1AtOPRnav9NS5iWcFomZcXJiNmxcCX3Gwp/PyIIlSFbQ9VNJaemo+uYFdjl IqQjob2kgNETE+kCO0oAZxpmp1ycvRd5pCciNxJktSDvWVfkOio= =oa2U -----END PGP SIGNATURE----- --=-=-=--