Dnia 2014-08-18, o godz. 15:37:26 Chris Reffett <creff...@gentoo.org> napisał(a):
> > > On August 18, 2014 11:11:56 AM EDT, "Michał Górny" <mgo...@gentoo.org> wrote: > >Dnia 2014-08-18, o godz. 09:22:46 > >Chris Reffett <creff...@gentoo.org> napisał(a): > > > >> On 8/18/2014 8:56 AM, hasufell wrote: > >> > Almost forgot, of course this does not work if you expect > >> > unpacker_src_unpacker() to run: > >> > inherit unpacker games base > >> > > >> > as well as > >> > inherit unpacker base games > >> > > >> > however > >> > inherit games unpacker base > >> > > >> > will work. > >> > > >> > And now... guess why the games herd made it a policy to always > >inherit > >> > games.eclass last. Because of the unpredictability of eclasses and > >that > >> > they may randomly add exported phase functions. It's a bit > >paranoid, but > >> > understandable, since we don't have any real rules here. > >> > > >> > So in the end 3 eclasses all tell you "inherit me last! really!". > >Good > >> > luck with figuring out how to make a gnome game with python and > >multilib > >> > support work together. I can predict the days such a review would > >take > >> > in #gentoo-sunrise. Not less than 3. > >> > > >> Would it be feasible to add a repoman check for situations like this, > >> where the behavior of a phase is dependent on inherit order? If so, > >it > >> seems reasonable to me to require explicit calls to eclass functions > >in > >> these cases to make it clear what's being called when. > > > >Right now, we have no kind of repoman for eclasses. If you have time to > >work on such a thing, please do. Otherwise, all we can do is put more > >checks in ebuilds but that triggers the warning for the wrong people... > > 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. People will be unhappy about it. Well, I will be unhappy about it. Maybe if we had different eclasses... but with what we have now, I'd rather order eclasses properly than redefine each phase. Maybe we could agree on something lighter, say, that src_configure() through src_install() should come from the same eclass. Also, please wrap your mails. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
