1 |
On Wed, Jun 11, 2008 at 12:06 PM, Ciaran McCreesh |
2 |
<ciaran.mccreesh@××××××××××.com> wrote: |
3 |
> On Wed, 11 Jun 2008 08:31:45 +0200 |
4 |
> Thomas de Grenier de Latour <tom.gl@××××.fr> wrote: |
5 |
>> On 2008/06/11, Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
6 |
>> > You're missing the cases where the cache isn't usable. |
7 |
>> |
8 |
>> I was not talking about generating cache entries, and neither were |
9 |
>> you. I've replied to you because you were suggesting that the "EAPI in |
10 |
>> ebuilds contents" solution had extra cost when _using_ valid cache |
11 |
>> entries (need to extract the EAPI from the ebuild before reading this |
12 |
>> cache entry), which i think can be easily avoided. |
13 |
> |
14 |
> And it does, since EAPI has to be known to use the cache contents. The |
15 |
> way it's handled currently is a hack that doesn't work with future EAPIs |
16 |
> defining new metadata. |
17 |
|
18 |
Fix that, then. And I understand that the code is already there in |
19 |
both portage and pkgcore to store the cache as key-value pairs rather |
20 |
than one-slot-per-key, and would be relatively trivial to add to |
21 |
paludis. |
22 |
|
23 |
Regards, |
24 |
-- |
25 |
Arun Raghavan |
26 |
(http://nemesis.accosted.net) |
27 |
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 |
28 |
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com |
29 |
-- |
30 |
gentoo-dev@l.g.o mailing list |