guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

proposal: make build failures explicit results in the store


From: Florian Paul Schmidt
Subject: proposal: make build failures explicit results in the store
Date: Wed, 25 Nov 2015 09:14:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

-----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-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]