On 01/19/2018 at 14:41 Ludovic Courtès writes: > Hi! > > Ricardo Wurmus <ricardo.wur...@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
