Hi,
On Wed, 08 Nov 2023 at 22:17, Maxim Cournoyer <maxim.courno...@gmail.com> wrote:
> I agree it looks tricky to get it right (and even trickier to prove/test
> for it) :-).
Yeah. I have tried a rough “proof-of-concept” i.e., two derivations:
one which deletes ’check’ phase and the other which deletes ’build’
phase and depends on the former.
Re: Turning off tests leads to a different store item
Simon Tournier <zimon.touto...@gmail.com>
Thu, 02 Nov 2023 18:02:18 +0100
id:86y1fgm6lh....@gmail.com
https://lists.gnu.org/archive/html/help-guix/2023-11
https://yhetil.org/guix/86y1fgm6lh....@gmail.com
In this simple case, it works. :-)
But to have something robust, IMHO, it would probably mean 1. create
other objects (record) different from <package> and revamp the build
systems. And then 2. rebuild many packages for 3. evaluate the ratio
between the number of packages that works this way vs the number of
packages that fails this way. Oof! That’s a fun project… :-)
> I think the lower fruits are in looking at making the test suite of the
> few common offenders more robust (using libfaketime or the likes) to
> prevent (re)occurrences of time bombs in the future.
I agree. On a side note, one of the issue is the time of some tests.
Sometimes, packaging is frustrating: build takes ages, then you fix some
tests, think it will be good, re-launch “guix build”, another test
failing, repeat. It could nice to be able to cache the result of the
build phase.
Cheers,
simon
