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