| 1 |
On Tue, 21 Mar 2017 17:30:29 +0100 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> On wto, 2017-03-21 at 17:05 +0100, Alexis Ballier wrote: |
| 5 |
> > On Tue, 21 Mar 2017 16:46:43 +0100 |
| 6 |
> > Michał Górny <mgorny@g.o> wrote: |
| 7 |
> > |
| 8 |
> > > Use --cache-file to reuse the previous check results in the |
| 9 |
> > > subsequent configure script runs. This gives a major speed |
| 10 |
> > > advantage (beating the previous parallel runs) and significant |
| 11 |
> > > CPU savings. |
| 12 |
> > |
| 13 |
> > Just in case (didn't try nor do I know the reasons of this), but I |
| 14 |
> > think this change deserves a round in ~arch: |
| 15 |
> > https://bugs.gentoo.org/show_bug.cgi?id=162875 |
| 16 |
> |
| 17 |
> confcache is a completely different business. The problem with |
| 18 |
> confcache is that it uses persistent, global cache for lots of |
| 19 |
> packages, which can easily get stale or provide corrupted data. Using |
| 20 |
> local cache is usually safe (except for very broken packages). |
| 21 |
|
| 22 |
|
| 23 |
yes you're right, but that still doesn't justify pushing straight to |
| 24 |
stable for a package in @system |
| 25 |
(the same applies to the other patches) |
Archives