Am Sonntag, dem 10.12.2023 um 17:28 +0200 schrieb Saku Laesvuori: > > 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. Yeah, it's not really good commit etiquette to drop a bunch of world- breaking builds on top of master. We mostly use feature branches for larger changes. OTOH, if it rebuilds less than 300 packages, it really is your call – the number of breakages is limited in that case too :)
> > 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. This is typically allowed when branching off, as few people will time- machine into an intermediate commit on an off-master branch safe for debugging some very arcane failures. > > 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). A reasonable way is to plan according to guix graph. Tackle the low- level nodes first and stack the high-level nodes on top. If two packages share immediate dependencies, but neither relies on the other, then any order is fine between these two. Cheers
