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).
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.
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“We must free ourselves of the hope that the sea will ever rest. We must learn
to sail in high winds.”
— Aristo Onassis (1906–1975)
