Re: A "busy beaver" approach to assisting package definition updates

[Ludovic Courtès]

Hey there!

Christopher Allan Webber <address@hidden> skribis:

> David Thompson and I had the good fortune to be able to hang out with
> the esteemed Gerald Sussman in his office over tea.  Topics were wide
> ranging, but one in particular has stuck in my mind as to how it could
> apply to Guix.

Awesome!

> Now obviously in Guix, we're trying to be very specific about linking,
> and it's done at package build time, not at compile time.  But still, we
> can mostly pull off the same thing using a continuous integration
> system, assuming we have enough resources; we already have tooling to
> look for the newest versions of packages, and we could possibly have a
> CI system try to write out a new package definition based on the latest
> version, try compiling it and see if it passes its tests... and then we
> can try to see if the packages that depend on it can also compile
> against it and pass their tests.  In this way we could automatically do
> the work of detecting and suggesting upgrades for many packages, and
> even finding out what they would break... *before* community members
> have to spend the effort to try it themselves.  It wouldn't be perfect,
> but it could be a big assist.  Perhaps there could be a web interface
> that shows "Here's a new definition of this package, it seems to build.
> Here's packages that depend on it which pass... these ones don't,
> perhaps they should be pinned to the old version or be investigated?"

Sure!  I think this sort of thing has been floating in the air in the
Nix & Guix realm.  For CI at <https://hydra.nixos.org/project/gnu>, at
one point we were building, for instance, Hurd + Mach + glibc all
straight from Git¹, or libgcrypt + GnuPG + all companion libs².

For the Hurd, that defines 3 axes along which code changes (Hurd, Mach,
glibc; well there’s a 4th axis which was Nixpkgs.)  So when a build
breaks, it means one of the changes on these axes, or a combination
thereof, is responsible for the breakage.

To find out which one, we could imagine Hydra/Cuirass automatically
making an N-dimensional dichotomy along all these axes.  Would be fun.


Back to Guix packages, I think we could certainly come up with a bot
that essentially runs ‘guix refresh -u’, builds everything that needs to
be built, and presents the result.  We already have most of the tooling
for this!  We could limit that to packages with at most N dependents,
for instance.  Anyone looking for a GSoC topic?  :-)

Thoughts?

Thanks for sharing!

Ludo’.


¹ https://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00019.html

² Of course it’s all broken now because the person who was taking care
  of it moved on to a side project.  :-)