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? 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. Paweł >> 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. >> >> 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 --- >> >> If ECLASS_PHASES is undefined, I think the default should be to not run >> the eclass phase functions. >> >> 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. >> >> > This proposal, seems reasonable, given my comments. I anticipate however > its biggest downside would be > the requirement to state *all* the functions you want, which would lead to > maintenance headaches > due to people forgetting to declare they wanted some function or other. > > So if you could sculpt it to be broader by default and have less scope for > developer error, that'd be an improvement. > > --- code start -- > ECLASS_EXCLUDE="foo_src_unpack bar_src_unpack" > inherit foo bar baz > > > --- code end --- > > here, src_unpack would be baz_src_unpack *regardless* of composition order > because "foo" and "bar" were barred from being used, and baz took > precedence as a result. > > If baz provides no src_unpack, then the ebuild in question is simply left > without one. > > You'll still need to declare src_unpack explicitly if you need use > conditional behaviour, however. >
signature.asc
Description: OpenPGP digital signature
