1 |
On Mon, 24 Dec 2007 11:19:18 +0000 |
2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
3 |
> > Which is fine. But then, the majority of devs shouldn't expect to be |
4 |
> > able to provide opinions when it comes to the more technical |
5 |
> > aspects. |
6 |
> > |
7 |
> Yes, but they can smell a nasty hack when they see one; starting with |
8 |
> the fact that the API is no longer as clean. |
9 |
|
10 |
Clearly not... |
11 |
|
12 |
> >> On a somewhat related note : I noticed that among the massive |
13 |
> >> thread, you have brought up several times the issue of cache |
14 |
> >> generation, saying that it was a complicated process. |
15 |
> >> |
16 |
> >> Maybe this process needs to be reworked before the whole EAPI issue |
17 |
> >> can be resolved? |
18 |
> > |
19 |
> > That's partly what the GLEP is doing. Making it any simpler, |
20 |
> > unfortunately, would involve either a huuuuuuge performance hit |
21 |
> > (we're talking two orders of magnitude here) or removing metadata |
22 |
> > from the ebuilds entirely -- neither of which are viable solutions. |
23 |
> > |
24 |
> Oh, I thought this wasn't about performance? Nor indeed about cache |
25 |
> generation. |
26 |
|
27 |
The GLEP is not about performance, but any solution that forces the |
28 |
introduction of a slowdown of more than, say, 20%, isn't viable. In |
29 |
particular, making a typical emerge -pv world take of the order of 0.1s |
30 |
per c/p-v's metadata that's needed (as a very rough idea, we're talking |
31 |
a thousand upwards of these on a typical system) isn't even remotely |
32 |
feasible. |
33 |
|
34 |
And no, the GLEP doesn't directly address cache generation. But |
35 |
equally, it can't ignore it simply because without some form of |
36 |
static metadata cache package managers can't be implemented in a way |
37 |
acceptable to end users. |
38 |
|
39 |
You see, there's this thing called the "big picture"... |
40 |
|
41 |
-- |
42 |
Ciaran McCreesh |
43 |
-- |
44 |
gentoo-dev@g.o mailing list |