1 |
On Sat, 15 Sep 2012 18:20:26 -0700 |
2 |
Brian Harring <ferringb@×××××.com> wrote: |
3 |
|
4 |
> On Sun, Sep 16, 2012 at 12:03:36AM +0200, Micha?? G??rny wrote: |
5 |
> > On Sat, 15 Sep 2012 13:33:18 -0700 |
6 |
> > Brian Harring <ferringb@×××××.com> wrote: |
7 |
> > > To demonstrate the gain of this, we basically take the existing |
8 |
> > > tree's deps, and re-render it into a unified DEPENDENCIES form. |
9 |
> > |
10 |
> > But in order to do this, we first have to decide exactly what kind |
11 |
> > of dependencies do we want to have. Then convert the tree to |
12 |
> > a separate-variable form with new dependencies. Then we can compare |
13 |
> > it with the DEPENDENCIES form and decide which one is better. |
14 |
> |
15 |
> Funny you mentioned that, I just finished tweaking pquery to generate |
16 |
> real world example unified dependencies; these *are* accurate, just |
17 |
> to be clear. |
18 |
|
19 |
But consider that for example Zac & AxS (correct me if I recall it |
20 |
correctly) considered making changing the meaning of RDEPEND to install |
21 |
them before the build, thus effectively making 'build,run' useless. |
22 |
|
23 |
> Total cache savings from doing this for a full tree conversion, for |
24 |
> our existing md5-cache format is 2.73MB (90 byes per cache entry). |
25 |
> Calculating the savings from the ebuild/eclass standpoint is |
26 |
> dependent on how the deps are built up, so I skipped that. |
27 |
|
28 |
You're storing the cache in a tarball? |
29 |
|
30 |
-- |
31 |
Best regards, |
32 |
Michał Górny |