1 |
Dnia 2014-08-18, o godz. 15:37:26 |
2 |
Chris Reffett <creffett@g.o> napisał(a): |
3 |
|
4 |
> |
5 |
> |
6 |
> On August 18, 2014 11:11:56 AM EDT, "Michał Górny" <mgorny@g.o> wrote: |
7 |
> >Dnia 2014-08-18, o godz. 09:22:46 |
8 |
> >Chris Reffett <creffett@g.o> napisał(a): |
9 |
> > |
10 |
> >> On 8/18/2014 8:56 AM, hasufell wrote: |
11 |
> >> > Almost forgot, of course this does not work if you expect |
12 |
> >> > unpacker_src_unpacker() to run: |
13 |
> >> > inherit unpacker games base |
14 |
> >> > |
15 |
> >> > as well as |
16 |
> >> > inherit unpacker base games |
17 |
> >> > |
18 |
> >> > however |
19 |
> >> > inherit games unpacker base |
20 |
> >> > |
21 |
> >> > will work. |
22 |
> >> > |
23 |
> >> > And now... guess why the games herd made it a policy to always |
24 |
> >inherit |
25 |
> >> > games.eclass last. Because of the unpredictability of eclasses and |
26 |
> >that |
27 |
> >> > they may randomly add exported phase functions. It's a bit |
28 |
> >paranoid, but |
29 |
> >> > understandable, since we don't have any real rules here. |
30 |
> >> > |
31 |
> >> > So in the end 3 eclasses all tell you "inherit me last! really!". |
32 |
> >Good |
33 |
> >> > luck with figuring out how to make a gnome game with python and |
34 |
> >multilib |
35 |
> >> > support work together. I can predict the days such a review would |
36 |
> >take |
37 |
> >> > in #gentoo-sunrise. Not less than 3. |
38 |
> >> > |
39 |
> >> Would it be feasible to add a repoman check for situations like this, |
40 |
> >> where the behavior of a phase is dependent on inherit order? If so, |
41 |
> >it |
42 |
> >> seems reasonable to me to require explicit calls to eclass functions |
43 |
> >in |
44 |
> >> these cases to make it clear what's being called when. |
45 |
> > |
46 |
> >Right now, we have no kind of repoman for eclasses. If you have time to |
47 |
> >work on such a thing, please do. Otherwise, all we can do is put more |
48 |
> >checks in ebuilds but that triggers the warning for the wrong people... |
49 |
> |
50 |
> I was thinking more ebuild-side. Example: my ebuild inherits both cmake-utils and games eclasses, and I don't explicitly define src_compile, repoman full could pop up a warning like "src_compile is ambiguous between cmake-utils_src_compile and games_src_compile, please explicitly define this phase and call the appropriate eclass function." I imagine that this would pop up a lot of warnings, but I feel like it would improve readability and make it explicit what should be going on where. I concede that it could make a lot more boilerplate code in ebuilds, so that's a potential issue, mostly just throwing out an idea here. |
51 |
|
52 |
People will be unhappy about it. Well, I will be unhappy about it. |
53 |
Maybe if we had different eclasses... but with what we have now, I'd |
54 |
rather order eclasses properly than redefine each phase. |
55 |
|
56 |
Maybe we could agree on something lighter, say, that src_configure() |
57 |
through src_install() should come from the same eclass. |
58 |
|
59 |
Also, please wrap your mails. |
60 |
|
61 |
-- |
62 |
Best regards, |
63 |
Michał Górny |