Re: [RFC] A simple draft for channels

[myglc2@gmail.com]

On 01/19/2018 at 14:41 Ludovic Courtès writes:

> Hi!
>
> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:
>
>> 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)
>>
>> Optional fields:
>>
>> * a description of the channel
>>
>> * a URL from where substitutes for the packages can be obtained (this
>>   will be backed by “guix publish”)
>>
>> * 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’d need to add the “guix channel” 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’s a git frontend).
>
> I think what you described above is “config” rather than “state.”
>
> To me, “state” 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 “guix pull” or “guix channel update”
> operation.
>
> The reflog thing is a feature we can already add to ‘guix pull’.  I
> think the migration to channels can be incremental.
>
>> It also authorizes the the substitute server’s public key.
>
> This would require root access.
>
>> Internally, it’s just like GUIX_PACKAGE_PATH in that the repos are 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 “globally” enable new substitute 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’t see any way around that
> (other than switching to the other model presented in Eelco’s thesis,
> which is to content-address derivation outputs—but I don’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’s okay.  It’s still an
>> improvement over plain GUIX_PACKAGE_PATH.
>>
>> I don’t think it has to be more complicated than that.  What do you
>> think?
>
> I agree!
>
> One thing that’s still an open question is how we should treat Guix
> itself in that channelized world.
>
> Should Guix be a “normal” channel?  It’s tempting to think of it as a
> regular channel; however, it’s definitely “special” in that it can
> update the ‘guix’ command, maybe guix-daemon & co., locale data, etc.
> How does that affect ‘guix channel’?

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