El mié, 27-02-2013 a las 18:10 +0100, hasufell escribió: > I don't want to start another useless rant here, because I perfectly > understand the issue with ABI specific headers. > > The problem is: > a) if you break a provider on purpose, then you should feel > somehow responsible for the consumers and not just dump testing and > fixing on your fellow devs > b) just test such things in an overlay first and see it explode, then > think about it again and ask on dev-ML if other people find it even > WORTH the hassle > > > The other thing is: > We still have the conflict with eclass-solution vs PM-solution > (multilib-portage) and I propose not to convert ANYTHING else until that > conflict is solved, even if it means a council vote (that's what I > actually think makes sense here). > I understand both sides and somehow find it appealing to have a quicker > solution, but since this could damage years of work on a portage fork I > think we should slow down here. > >
Personally I don't think mgorny "broke a provider on purpose", he should have released it hardmasked, but thinking he wanted to break testing on purpose looks excessive to me. Also, most of that committed stuff was tested for some time in x11 overlay, no? (not sure if probably freetype was missed by some error, but clearly the transition to the eclasses providing native multilib were tested "on purpose" in that overlay before moving to the tree). About PM-solution... I can't remember how many years we are waiting it for being approved, and neither remember what was blocking it for inclusion in eapi5 (as that threads usually end up being fairly long and ending with blockers like PMS documentation changes and so :( ) I also remember this "conflict" between portage-multilib and eclasses ways were discussed some weeks ago here (I thought specially between mgorny and... aballier?)
signature.asc
Description: This is a digitally signed message part
