Hello Konrad, Konrad Hinsen skribis: >> 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. True. Manifests can rely on fewer details of the API than a channel though, particularly if they use ‘specifications->manifests’. (BTW code in channels could use ‘specification->package’ as well to increase decoupling a bit.) > 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. Yeah. Thanks, Ludo’.