2018-01-19 9:24 GMT+01:00 Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>:

> Hi Guix,
>
> I’d like to retire GUIX_PACKAGE_PATH as the main way to get third-party
> packages, because we can’t really keep track of packages that were added
> or redefined in this way.  I want to replace it with slightly more
> formal “channels”.
>
> 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.
>
> 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).  It also
> authorizes the the substitute server’s public key.
>
> 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?)
>
> 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’s okay.  It’s 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’t think it has to be more complicated than that.  What do you
> think?
>
> --
> Ricardo
>
> In general, I like it and would love to play around with this soon.

- Jelle

[1]: https://semver.org/