Dnia 2014-08-16, o godz. 16:54:28 William Hubbs <willi...@gentoo.org> napisał(a):
> The initial proposal is to change this behaviour so that the PMS default
> phase functions call all matching phase functions from inherited
> eclasses in sequence.
>
> For example:
>
> - your ebuild inherits foo and bar and each of them have src_unpack
> functions. With this new behaviour, the default src_unpack would run
> foo_src_unpack, bar_src_unpack, then perform its own actions.
Why doesn't it call default_src_unpack too?
> I strongly oppose this change, because I feel it will make our
> entire tree very unpredictable at best. I realize this might eliminate
> boilerplating from our tree. Weighing that against the possible
> ramifications in this big of a change in automagic behaviour, I think
> the cost is much higher than the gain.
'Unpredictable' is very lightly said. 'Complete mayhem' seems much more
appropriate.
Right now, finding proper phase functions may be a bit hard due to
indirect inherits. Imagine all the fun of debugging phase functions
when every single indirect inherits adds to the stack. I don't want
even to discuss the issue of ordering them all.
For example, a quick grep suggests that 72 eclasses declare
src_compile(). Now imagine how many eclasses end up inherited in more
complex ebuilds. Of course, the final number would be smaller since
many eclasses will simply have to drop phase functions to avoid forcing
every single ebuild to redefine phases to avoid colliding behavior.
However, I exaggerate a bit here. The issue won't hit too many people
because the learning curve would look more like a cliff which you will
be climbing up upside down using only your tongue, during a storm.
> I am also not very comfortable with our current state, because it has
> a lot of uncertainty in terms of how the eclass phase functions are
> called.
That is not really a problem of PMS behavior but a problem with
the eclasses. If eclasses were done at least semi-reasonably, you
would be able to easily guess which phase functions are exported by
which eclass.
> My counter proposal to this is that we stop calling eclass phase
> functions automatically, and to minimize the amount of boilerplating
> we would have to do, we use a variable, such as ECLASS_PHASES which
> would be defined at the ebuild level and contain a list of the eclass
> phase functions we want to run automatically.
>
> Going back to my previous example, say your ebuild does the following:
>
> -- code begins here --
>
> inherit foo bar
>
> # Foo and bar both have src_unpack and src_install functions.
> # we want foo's src_unpack and bar's src_install:
>
> ECLASS_PHASES="foo_src_unpack
> bar_src_install"
>
> -- code ends here ---
And how is this exactly different than:
src_unpack() { foo_src_unpack; }
src_install() { bar_src_install; }
forced by your previous idea? As I see it, it's just a redundant way of
doing the same thing. A few bytes shorter maybe, at the cost of having
to control and consider another variable.
What happens if ebuild specifies both ECLASS_PHASES="foo_src_unpack"
and explicit src_unpack()?
> If ECLASS_PHASES is undefined, I think the default should be to not run
> the eclass phase functions.
Do we want to run default EAPI phases? Do we want to have an extra
variable to control these?
> Yes, this means there is some boilerplating. However, there are some
> strong advantages:
>
> - this is no longer dependent on order of inheritance.
> - The ebuild author knows exactly which eclass phase functions will
> be run.
>
> Thoughts?
The current behavior compared to the two extremes suggested here sounds
like a good compromise. It's not perfect but it works very well for
most of the ebuilds, keeping only a few overly verbose and a few
unpredictable.
The first suggested idea is the kind of extreme trying to solve
the overly verbose ebuilds. While it could work in the end, it will
certainly make getting all ebuilds and eclasses right a pain. Moreover,
it is full of pitfalls and hidden issues.
The second idea is the complete opposite extreme. It kills all
automation, forcing verbose references in every ebuild. Imagine all
those simple Perl modules that have to list all the phase functions...
and imagine all the extra pitfalls of missing phase function calls.
That said, I suggest you focus your efforts on solving the real issue
-- that is, fixing the eclasses -- rather than trying to shoehorn
an ugly workaround into PMS.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
