From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Paul Schmidt Subject: proposal: make build failures explicit results in the store Date: Wed, 25 Nov 2015 09:14:52 +0100 Message-ID: <56556DFC.3050402@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1VEA-0005uf-QB for guix-devel@gnu.org; Wed, 25 Nov 2015 03:14:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1VE6-0000H4-NJ for guix-devel@gnu.org; Wed, 25 Nov 2015 03:14:58 -0500 Received: from mout.gmx.net ([212.227.17.20]:52339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1VE6-0000Gz-EE for guix-devel@gnu.org; Wed, 25 Nov 2015 03:14:54 -0500 Received: from [192.168.1.241] ([93.130.30.14]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LjuR3-1ackia1maP-00bq9x for ; Wed, 25 Nov 2015 09:14:53 +0100 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: guix-devel@gnu.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, currently I'm trying my hands on building _all_ available packages on the x86_64 platform in a qemu-vm (with the intended aim to later publish them to maybe take some load off hydra), but I came across an issue that might have an easy solution but I'm not sure exactly what's the right way to proceed. Basically what I did right now was this: for n in `guix package -A | cut -f1`; do guix build --no-substitutes\ - --max-silent-time=10 "$n" || true; done Watching it run I noticed something though: Some package, let's call it "foo1", seemed to have package "bar" as depencency (the concrete example for bar was Qt5 which is probably why I noticed ;)), but the bar build failed. So building foo1 failed, too. So far so good, aside from foo1's and bar's failure everything is fine. Now another package, foo2, comes along and it, too, depends on bar. Since bar failed to build previously guix thinks it's a swell idea to retry building bar. This, of course, is silly, and in this concrete example, Qt5, a massive waste of cpu cycles and the only good thing it does is to bring the universe closer to the heat death. Afaict the real problem is that the functional approach is slightly broken here (being functional is fine, just the implementation is broken). The attempt to build bar _had_ a result. That result was a build failure and as such it should be explicitly represented in the store such that when another attempt to build bar comes along, the result is already known: build failure. And this should make the build of foo2 fail immediately, too, since one of its dependencies failed to build. Once the package definition of bar changes, there's a new store path for its result and the build will be retried. Do I miss something here? What do you think? Have fun, Flo - -- https://fps.io -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWVW37AAoJEA5f4Coltk8ZpDsIAJNXNMs73RJvPa+XMwjLLnIb zckxdP12xDzq4CH+P4ehqSip+6evTfnaW+9VlYLjTdw7maD6VNk1CFIaOUObAxSI wwaX1JsHEzoJgaymHOSa+ZSoa8U8BczZeOkoiupJVQevSTryC0nHvX5iWOxJdNC5 /AzGo/VfvYVIciHtDwzcq7cExS5NRBZSvwoaeITdtFk+/XwkQJ8d78eH+EUBYoQK saoy4pklnpesr4jofmI32yZ9lxONkmYd1etpwIyirIuEnxsqzGk9EHTTBO4MmrJg B3OQnh/fNoqwToQblWIn/tEAJZO7h0a2clmaWNDf0wwMIfO2NNfMotAWYzXBj1A= =6KOG -----END PGP SIGNATURE-----