Hi Ludo, > Mark’s concern is not about whether packages are the latest version, > etc. It’s about the constraints that could result from widespread > development of channels outside Guix proper: technically all of Guix is That's how I understood it as well. If/when Guix becomes somebody else's dependency, then there will be pressure on stability in Guix itself. My point is that this will happen anyway if Guix is adopted more widely. Every manifest file, personal or shared as part of a software package ("guix.scm"), relies on the same technical details as a channel. Introducing channels only makes the issue more visible. And this is really the same issue as with the stability of the packages themselves, Guix being a kind of superpackage. Most people want agility for the software layer they are most concerned with, and stability for all layers below it. For Mark (and certainly others here), Guix happens to be the layer they are most concerned with. > I’d rather not build fancy mechanisms just for the sake of external > channels, and I certainly don’t want to commit to API stability. We At this point, certainly not. But I agree with Mark that, if channels "take off", there will be pressure in that direction. Konrad.