On Tue, 21 Mar 2017 19:33:46 +0100 Michał Górny <mgo...@gentoo.org> wrote:
> On wto, 2017-03-21 at 17:55 +0100, Alexis Ballier wrote: > > On Tue, 21 Mar 2017 17:30:29 +0100 > > Michał Górny <mgo...@gentoo.org> wrote: > > > > > On wto, 2017-03-21 at 17:05 +0100, Alexis Ballier wrote: > > > > On Tue, 21 Mar 2017 16:46:43 +0100 > > > > Michał Górny <mgo...@gentoo.org> wrote: > > > > > > > > > Use --cache-file to reuse the previous check results in the > > > > > subsequent configure script runs. This gives a major speed > > > > > advantage (beating the previous parallel runs) and significant > > > > > CPU savings. > > > > > > > > Just in case (didn't try nor do I know the reasons of this), > > > > but I think this change deserves a round in ~arch: > > > > https://bugs.gentoo.org/show_bug.cgi?id=162875 > > > > > > confcache is a completely different business. The problem with > > > confcache is that it uses persistent, global cache for lots of > > > packages, which can easily get stale or provide corrupted data. > > > Using local cache is usually safe (except for very broken > > > packages). > > > > > > yes you're right, but that still doesn't justify pushing straight to > > stable for a package in @system > > (the same applies to the other patches) > > If you really believe users should suffer a 30-minute rebuild for > a build-time fix, sure. that's the term 'fix' or the cache giving exactly the same results which i'm unsure about
