1 |
On Sun, Sep 16, 2012 at 03:39:22PM +0800, Ben de Groot wrote: |
2 |
> On 16 September 2012 09:20, Brian Harring <ferringb@×××××.com> wrote: |
3 |
> > Dumps are at |
4 |
> > http://dev.gentoo.org/~ferringb/unified-dependencies-example/ . |
5 |
> > |
6 |
> > Herds, if you want to see what your pkgs would look like, look at |
7 |
> > http://dev.gentoo.org/~ferringb/unified-dependencies-example/herds/ . |
8 |
> > |
9 |
> > If you'd like to see an *example effect* it has on what gets displayed |
10 |
> > to the user (aka, after all major use conditionals are stripped), look |
11 |
> > at |
12 |
> > http://dev.gentoo.org/~ferringb/unified-dependencies-example/user-visible.txt |
13 |
> > ; warning, that's a 55MB file. The syntax in use there isn't great, |
14 |
> > but as said, it's an example. |
15 |
> > |
16 |
> > ... |
17 |
> > |
18 |
> > Additionally, the form used here makes *no assumption about default |
19 |
> > context*; in any final solution we use, a default context would be |
20 |
> > wise- say build,run. Again, an example of what I mean. |
21 |
|
22 |
The dumps were regenerated; a default context of 'build,run' was |
23 |
added. Basically in the absense of an explicit dep: targetting, |
24 |
dep:build,run is assumed. |
25 |
|
26 |
Essentially it makes the deps cleaner to read for the common case, |
27 |
while also reducing the footprint at the cache, and vdb level; see |
28 |
http://dev.gentoo.org/~ferringb/unified-dependencies-example/vdb-effect.txt |
29 |
|
30 |
|
31 |
> Thanks. I have given it a quick overview for the qt herd. I still |
32 |
> don't see what using DEPENDENCIES adds to what we do now with separate |
33 |
> *DEPEND variables. I see no convincing reason to change what we do. |
34 |
|
35 |
Ok, so here's some stats: in the tree, we have 31360 ebuilds, and 194 |
36 |
eclasses; grand total of 31554 sources of metadata content (I say |
37 |
metadata since vapier has eblits in use which are just phase |
38 |
functions- I'm not scanning those intentionally). |
39 |
|
40 |
Doing some simple scans of the tree, here's some stats; note these |
41 |
stats are duplicated in the glep (they're nice selling points, thus |
42 |
might as well): |
43 |
|
44 |
1) 746 hits in the tree for COMMON_DEPEND; that's 2%, and the usages |
45 |
I'm aware of have been for literally, what it sounds like- depends |
46 |
that are both DEPEND and RDEPEND. |
47 |
|
48 |
2) scanning for assignments of RDEPEND=.*|$\{?DEPEND\}? gets a hit on |
49 |
5343 unique sources. Searching for the inverse gets a hit on 10008 |
50 |
unique sources. Meaning that right there, ~48.6% of the tree is |
51 |
duplicating deps between the two forms. This puts us to 16083 unique |
52 |
sources in the tree that would benefit in some form (~51%). |
53 |
|
54 |
3) What's interesting about that 51% is the eapi groupings; in EAPI4, |
55 |
the autosetting of RDEPEND="${RDEPEND:-${DEPEND}}" was discontinued. |
56 |
Roughly 50% of the initial 51% match is EAPI4; the rest are eapi0-3. |
57 |
|
58 |
4) Again, keep in mind that the grep's in use above are single line |
59 |
matches- I'm definitely missing some ebuilds, and for complex |
60 |
dependencies that are appended/set by the eclass, likely missing a lot |
61 |
of that too. |
62 |
|
63 |
So... basically, people are already doing this manually with their own |
64 |
intermediate vars. |
65 |
|
66 |
Just a rough but mildly entertaining stat there's basically 8.38MB |
67 |
worth of normalized, literal fricking dependency; using a crappy algo |
68 |
(rather than a human doing the deps who can do it better), 37.4% |
69 |
(3.1MB) of that is removed via going to dependencies. It goes |
70 |
without saying that this would be a helluva lot less torturous on a |
71 |
proper PM implementation that parses the tree once, and renders- let |
72 |
alone repoman being able to avoid repeat scans of things it already |
73 |
has examined. |
74 |
|
75 |
Mind you, portage doesn't do that, but this would be good incentive to |
76 |
do a proper tree. :) |
77 |
|
78 |
|
79 |
> As I've said before on IRC, we need a good costs/benefits overview. |
80 |
> Right now I only see costs (migrating ebuilds and eclasses) and no |
81 |
> benefits. |
82 |
|
83 |
Offhand... I wouldn't be pushing for this if I didn't think this would |
84 |
be a boon over all- both for devs, and PMs. |
85 |
|
86 |
I think the actual 'cost' probably got lost in the noise of the |
87 |
various flames; what I'm proposing is basically zero cost for devs, it |
88 |
shoves the work to the PM, leaving the option for devs to do a more |
89 |
fine grained form if they can. |
90 |
|
91 |
I'm starting a seperate thread w/ a glep for this; I think you should |
92 |
take a look at the exact details of the specification including how |
93 |
DEPEND/RDEPEND/PDEPEND are handled in parallel to DEPENDENCIES (short |
94 |
version: if existent, they're automatically folded into DEPENDENCIES |
95 |
in my proposal); the end result is basically zero pain transition, |
96 |
while enabling us to start getting gains. |
97 |
|
98 |
Cheers- |
99 |
~brian |