| 1 |
Brandon Mintern ha scritto: |
| 2 |
> I had thought the same thing myself some time ago, and I discovered |
| 3 |
> that there had been work on a FEATURE called confcache. I believe it |
| 4 |
> was abandoned, though, due to major difficulties. This is merely a |
| 5 |
> guess, but I think some of the problems arise in that some of the |
| 6 |
> things that are checked for actually change as a package is installed |
| 7 |
> or updated (e.g. checking gcc version). This means that each package |
| 8 |
> being installed would have to somehow flag confcache and indicate that |
| 9 |
> it has changed, and confcache would have to keep a list of all these |
| 10 |
> cached values and their dependencies. |
| 11 |
|
| 12 |
What was the problem with that? Ebuilds of stuff like gcc could be |
| 13 |
tailored to flag confcache. Otherwise, emerge could do the relevant |
| 14 |
checks before emerging the first package, and be trained to do them |
| 15 |
again after a known "troublesome" package has been emerged. |
| 16 |
|
| 17 |
I understand this requires coordination and maintaining, of course, and |
| 18 |
that's the non-trivial part, I guess. However, are there many packages |
| 19 |
affecting common configure checks? If they are, say, less than 10 |
| 20 |
affecting 80% of configure flags, it seems worth the hassle. If troubles |
| 21 |
arise, one can quickly try with confcache disabled, and debug. |
| 22 |
|
| 23 |
Heck, I'd help with it myself, if only I had some confidence with |
| 24 |
portage code and C compilation (However, I know Python, FWIW) |
| 25 |
|
| 26 |
m. |
| 27 |
|
| 28 |
|
| 29 |
-- |
| 30 |
gentoo-user@l.g.o mailing list |
Archives