Hi Ludo, Ludovic Courtès writes:
> Hi Alex, > > (Cc’ing <https://bugs.gnu.org/32022> and <https://bugs.gnu.org/26608>, > which are related.) > > Alex Sassmannshausen <a...@pompo.co> skribis: > >> I don't know if this is what Konrad desires, but from my perspective, a >> desirable part of the definition of stable would be a that the build >> farms have produced a set of binaries/substitutes for a given Guix >> revision that is "good enough". > > I just had a bright idea (yes!): this can be addressed by writing > something like this in ~/.config/guix/channels.scm: > > (map latest-commit-with-substitutes-available > %default-channels) > > The hypothetical ‘latest-commit-with-substitutes-available’ would use > (git) and (guix ci) to find the latest commit for which substitutes of > interest are available, and would return: > > (channel > ;; … > (commit "cabbag3")) ;the ideal commit This sounds incredibly interesting — and it is testament once again to the power of Guix that this kind of solution could be feasible! Thinking this through in my head somewhat, I had the following thoughts: - This procedure is invoked client side, where the channel is defined - That means the git searching is done client side, on every invocation of guix (I guess this might be cacheable?) - So the downside vis-a-vis a maintained "stable branch" would be a price in performance as experienced by the end user - The upside of course would be automatic curation of a stable branch that saves a ton of volunteer effort and work I have no idea what the performance cost would be. I guess you would use "guix weather" to turn the set of requested packages into a manifest which can then be checked with it. So the cost would be one of the following scenarios: Option a) - fetch set of packages in a given commit - query guix weather for 100% substitutes - iterate until a match - then perform the appropriate guix pull Option b) - perform a guix pull to the latest commit - query guix weather for 100% substitutes - until success, step back one step at a time through guix pull (because of the cost of guix pull this seems unfeasible) Option c) Implement some form of substitute cache set querying on build farms, as part of guix weather, so the 100% match is done on the build farm instead of the client. Dunno. There may be some things that already exist in Guix land that I'm missing. It's a super exciting approach for sure. > This has to be done with great care to prevent a downgrade attack and to > make sure the user doesn’t miss out on security updates, but maybe we > could provide a procedure that makes reasonable choices. Right — so at the very least it would have to prevent us going "back in time" from the guix pull commit we are currently at. The question of security updates is tricky at the moment already — I would hazard a guess that many people bail out of upgrading when they can't get substitutes for their entire profile / system right now, which means they are not getting security upgrades for package (a) when a substitute for (b) fails. Thanks for your thoughts — super intriguing! Alex
