Attila Lendvai <[email protected]> writes: > i think an abstraction is missing here which is causing some confusion. > > there are two histories here, mostly conflated currently: > > 1. the git log -- this one is obvious > > 2. something like a "guix log" > > the "guix log" is something like what e.g. the CI builds. IIUC, cuirass > currently makes multi-commit steps in 1), and it's somewhat coincidental > which git commits it will pick up and build. this is not representable in the > model guix currently uses. > > i.e. if i guix pull into a specific git commit that has never been picked up > by cuirass, then i'll potentially never have 100% substitutes, not matter how > long i'll wait (depending on what packages got invalidated by the > intermittent commits).
Right. That makes sense, thanks for pointing it out. > the introduction of 2) could also make it possible to describe inter-channel > dependencies, which could open the path for many user-facing features, like > e.g. not pulling the main channel until another channel, which is a required > dependency for the config, is not also updated, and marked so in the domain > of 2). > > and something in the domain of 2) could be used to mark/represent commits > that have been fully built by the CI. > > this is a very vague idea, and i cannot judge whether the added complexity is > clearly worth it. I think that would be worth exploring. Best regards, Sergio
