2018-01-19 9:24 GMT+01:00 Ricardo Wurmus <ricardo.wur...@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/
