From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: A "busy beaver" approach to assisting package definition updates Date: Tue, 28 Mar 2017 21:44:11 +0200 Message-ID: <87o9wltcdw.fsf@gnu.org> References: <877f3adcgs.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csx2R-0000XB-0g for guix-devel@gnu.org; Tue, 28 Mar 2017 15:44:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csx2N-0006CF-Ry for guix-devel@gnu.org; Tue, 28 Mar 2017 15:44:19 -0400 In-Reply-To: <877f3adcgs.fsf@dustycloud.org> (Christopher Allan Webber's message of "Mon, 27 Mar 2017 09:24:35 -0500") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Christopher Allan Webber Cc: guix-devel@gnu.org Hey there! Christopher Allan Webber 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 , at one point we were building, for instance, Hurd + Mach + glibc all straight from Git=C2=B9, or libgcrypt + GnuPG + all companion libs=C2=B2. For the Hurd, that defines 3 axes along which code changes (Hurd, Mach, glibc; well there=E2=80=99s 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 =E2=80=98guix refresh -u=E2=80=99, 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=E2=80=99. =C2=B9 https://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00019.html =C2=B2 Of course it=E2=80=99s all broken now because the person who was tak= ing care of it moved on to a side project. :-)