guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] A simple draft for channels


From: Ludovic Courtès
Subject: Re: [RFC] A simple draft for channels
Date: Fri, 19 Jan 2018 14:41:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hi!

Ricardo Wurmus <address@hidden> 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’?

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]