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