> 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