Dnia 2014-08-17, o godz. 09:06:04 "Paweł Hajdan, Jr." <phajdan...@gentoo.org> 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
signature.asc
Description: PGP signature
