Re: [RFC] A simple draft for channels

[Chris Marusich]

Hi Ricardo,

This is a great start - I'm excited to playing with a prototype!

Ricardo Wurmus <address@hidden> writes:

> As a first implementation of channels I’d just like to have a channel
> 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 “guix publish”)

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’d need to add the “guix channel” 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’s 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’s 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!

-- 
Chris

signature.asc
Description: PGP signature