Re: [gentoo-dev] rfc: calling all eclass phase functions by default

[Michał Górny]

Dnia 2014-08-17, o godz. 09:06:04
"Paweł Hajdan, Jr." <phajdan.jr@g.o> napisał(a):

> On 8/17/14, 12:32 AM, Kent Fredric wrote:
> > Collison systems I've seen usually do one of two things:
> >
> > - In the event of a collision, demand the consumer resolve the problem by
> > redefining the function the collision occurs on in terms of its composite
> > parts. ( which is basically what we already do )
> > - Declare syntax to "exclude" a potential collision from either composite
> > part.
> >
> > Our only real difference at present is unlike these systems, we assume we
> > can simply guess which one wins and just choose it automatically, where
> > collision systems tend to force you to deal with the situation if any
> > collision occurs.
>
> This makes sense to me. Can we consider starting with just a repoman
> warning for the collision cases?

Not really. First, you have to run a policy that prohibits solving them
through inherit order through QA. And saying for myself, I doubt I
would vote for a proposal which forces me to write more ebuild code.

Once QA agrees on a policy, we can add a matching repoman check.
Otherwise, it's full of false positives and a topic of bikeshed,
and then it is reverted.

> The warning would make the problem more visible to ebuild writers. Then
> we already have a solution that works, i.e. explicitly defining the
> phase function in the ebuild, possibly calling the eclass functions.
>
> My understanding is people not being aware of the problem is the main
> issue here, not the ability to address it.

What we could do is printing the phase function names when starting
them, e.g.:

  >>> [foo_src_compile] Compiling sources in ...

As for another idea, we could warn if an eclass overrides phase
function via implicit inherit without redefining it. As I see it, this
is the biggest issue here, and a solution that's relatively easy to
accept.

-- 
Best regards,
Michał Górny