1 |
Dnia 2014-08-18, o godz. 09:22:46 |
2 |
Chris Reffett <creffett@g.o> napisał(a): |
3 |
|
4 |
> On 8/18/2014 8:56 AM, hasufell wrote: |
5 |
> > Almost forgot, of course this does not work if you expect |
6 |
> > unpacker_src_unpacker() to run: |
7 |
> > inherit unpacker games base |
8 |
> > |
9 |
> > as well as |
10 |
> > inherit unpacker base games |
11 |
> > |
12 |
> > however |
13 |
> > inherit games unpacker base |
14 |
> > |
15 |
> > will work. |
16 |
> > |
17 |
> > And now... guess why the games herd made it a policy to always inherit |
18 |
> > games.eclass last. Because of the unpredictability of eclasses and that |
19 |
> > they may randomly add exported phase functions. It's a bit paranoid, but |
20 |
> > understandable, since we don't have any real rules here. |
21 |
> > |
22 |
> > So in the end 3 eclasses all tell you "inherit me last! really!". Good |
23 |
> > luck with figuring out how to make a gnome game with python and multilib |
24 |
> > support work together. I can predict the days such a review would take |
25 |
> > in #gentoo-sunrise. Not less than 3. |
26 |
> > |
27 |
> Would it be feasible to add a repoman check for situations like this, |
28 |
> where the behavior of a phase is dependent on inherit order? If so, it |
29 |
> seems reasonable to me to require explicit calls to eclass functions in |
30 |
> these cases to make it clear what's being called when. |
31 |
|
32 |
Right now, we have no kind of repoman for eclasses. If you have time to |
33 |
work on such a thing, please do. Otherwise, all we can do is put more |
34 |
checks in ebuilds but that triggers the warning for the wrong people... |
35 |
|
36 |
-- |
37 |
Best regards, |
38 |
Michał Górny |