1 |
On 16 September 2012 21:15, Brian Harring <ferringb@×××××.com> wrote: |
2 |
> On Sun, Sep 16, 2012 at 03:39:22PM +0800, Ben de Groot wrote: |
3 |
>> Thanks. I have given it a quick overview for the qt herd. I still |
4 |
>> don't see what using DEPENDENCIES adds to what we do now with separate |
5 |
>> *DEPEND variables. I see no convincing reason to change what we do. |
6 |
> |
7 |
> Ok, so here's some stats: in the tree, we have 31360 ebuilds, and 194 |
8 |
> eclasses; grand total of 31554 sources of metadata content (I say |
9 |
> metadata since vapier has eblits in use which are just phase |
10 |
> functions- I'm not scanning those intentionally). |
11 |
> |
12 |
> Doing some simple scans of the tree, here's some stats; note these |
13 |
> stats are duplicated in the glep (they're nice selling points, thus |
14 |
> might as well): |
15 |
> |
16 |
> 1) 746 hits in the tree for COMMON_DEPEND; that's 2%, and the usages |
17 |
> I'm aware of have been for literally, what it sounds like- depends |
18 |
> that are both DEPEND and RDEPEND. |
19 |
> |
20 |
> 2) scanning for assignments of RDEPEND=.*|$\{?DEPEND\}? gets a hit on |
21 |
> 5343 unique sources. Searching for the inverse gets a hit on 10008 |
22 |
> unique sources. Meaning that right there, ~48.6% of the tree is |
23 |
> duplicating deps between the two forms. This puts us to 16083 unique |
24 |
> sources in the tree that would benefit in some form (~51%). |
25 |
> |
26 |
> 3) What's interesting about that 51% is the eapi groupings; in EAPI4, |
27 |
> the autosetting of RDEPEND="${RDEPEND:-${DEPEND}}" was discontinued. |
28 |
> Roughly 50% of the initial 51% match is EAPI4; the rest are eapi0-3. |
29 |
> |
30 |
> 4) Again, keep in mind that the grep's in use above are single line |
31 |
> matches- I'm definitely missing some ebuilds, and for complex |
32 |
> dependencies that are appended/set by the eclass, likely missing a lot |
33 |
> of that too. |
34 |
> |
35 |
> So... basically, people are already doing this manually with their own |
36 |
> intermediate vars. |
37 |
|
38 |
And this works fine, so it doesn't warrant a cosmetic change. |
39 |
|
40 |
> Just a rough but mildly entertaining stat there's basically 8.38MB |
41 |
> worth of normalized, literal fricking dependency; using a crappy algo |
42 |
> (rather than a human doing the deps who can do it better), 37.4% |
43 |
> (3.1MB) of that is removed via going to dependencies. It goes |
44 |
> without saying that this would be a helluva lot less torturous on a |
45 |
> proper PM implementation that parses the tree once, and renders- let |
46 |
> alone repoman being able to avoid repeat scans of things it already |
47 |
> has examined. |
48 |
> |
49 |
> Mind you, portage doesn't do that, but this would be good incentive to |
50 |
> do a proper tree. :) |
51 |
|
52 |
PM internals are not really relevant to us developers. Just make it work... ;-) |
53 |
|
54 |
The current *DEPEND system works. So again, I don't see a convincing |
55 |
reason for change. |
56 |
|
57 |
>> As I've said before on IRC, we need a good costs/benefits overview. |
58 |
>> Right now I only see costs (migrating ebuilds and eclasses) and no |
59 |
>> benefits. |
60 |
> |
61 |
> Offhand... I wouldn't be pushing for this if I didn't think this would |
62 |
> be a boon over all- both for devs, and PMs. |
63 |
> |
64 |
> I think the actual 'cost' probably got lost in the noise of the |
65 |
> various flames; what I'm proposing is basically zero cost for devs, it |
66 |
> shoves the work to the PM, leaving the option for devs to do a more |
67 |
> fine grained form if they can. |
68 |
|
69 |
As soon as you expose this to devs (ebuild/eclass developers and |
70 |
maintainers), you can no longer talk about zero cost. |
71 |
|
72 |
We either have the enormous cost of migrating the whole tree to the |
73 |
new system — which I understand you are not advocating because of the |
74 |
cost; or we have the (lower, but not zero) cost of maintaining two |
75 |
systems in the tree, which developers will have to know and understand |
76 |
in order to be able to deal with them correctly. The latter will also |
77 |
make eclasses needlessly more complex. |
78 |
|
79 |
So in my opinion it is folly either way, because the costs are high, |
80 |
and the benefits only cosmetic. |
81 |
|
82 |
> I'm starting a seperate thread w/ a glep for this; I think you should |
83 |
> take a look at the exact details of the specification including how |
84 |
> DEPEND/RDEPEND/PDEPEND are handled in parallel to DEPENDENCIES (short |
85 |
> version: if existent, they're automatically folded into DEPENDENCIES |
86 |
> in my proposal); the end result is basically zero pain transition, |
87 |
> while enabling us to start getting gains. |
88 |
|
89 |
Which gains? The glep only talks about cosmetics... |
90 |
|
91 |
-- |
92 |
Cheers, |
93 |
|
94 |
Ben | yngwin |
95 |
Gentoo developer |
96 |
Gentoo Qt project lead, Gentoo Wiki admin |