> Hi Saku, > > Am Freitag, dem 08.12.2023 um 10:42 +0200 schrieb Saku Laesvuori: > > Hi, > > > > I'm planning on refreshing Guix's haskell packages as my fix for > > https://issues.guix.gnu.org/66347 requires rebuilding all of them > > anyway. Should I try to keep commits small with only one update per > > commit (which is more work but managable if I don't care about the > > commits being buildable) or should I try to keep them buildable (i.e. > > update everything in one commit)? It is quite certain that most of > > them will not build after updating ghc or a subset of their > > dependencies, so making many small commits would cause nearly all of > > them to be unbuildable. > > Define "buildable" and "unbuildable".
I used these definitions: a buildable commit does not have build failures (or at least no new ones). An unbuildable commit introduces new build failures (in this case a lot of them). Buildable commits are safe spots to land on with time-machine in the sense that the packages defined in them can be used. I expect it would be very painful to try jumping to past commits with time-machine if a large portion of the commits in Guix were unbuildable. > Depending on the context, it may be fine or even required to break > dependant packages for a short while and update them along a longer > series. I guess "required" here means that in some cases Guix's policy is to prefer small commits over buildable commits (with the previous definition). I at least don't see any technical reasons why it would be required. The question then becomes whether that policy applies in this case. > However, in each commit at least the package touched in that > commit ought to build. This should, of course, be theoretically possible with at least one update order but I don't know how would I discover that order (more efficiently than by trial and error. I don't want to try ~800² different combinations). - Saku
signature.asc
Description: PGP signature
