Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Chris Reffett <creffett@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: calling all eclass phase functions by default
Date: Mon, 18 Aug 2014 20:08:18
Message-Id: 20140818220846.43149208@pomiot.lan
In Reply to: Re: [gentoo-dev] rfc: calling all eclass phase functions by default by Chris Reffett
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

Attachments

File name MIME type
signature.asc application/pgp-signature