On 08/10/2013 02:22 AM, Michał Górny wrote: > Dnia 2013-08-10, o godz. 01:14:52 > Zac Medico <[email protected]> napisał(a): > >> On 08/10/2013 12:48 AM, Michał Górny wrote: >>>> Are we sure that this thing really belongs in the profile, rather than >>>> something that's defined in ebuilds? Or maybe we should have both? >>> >>> Well, AFAICS we have three cases: >>> >>> 1. kernel modules that all are installed to a common location >>> and therefore global collision/uninstall ignore setting works fine, >>> >>> 2. Python compiled files that all are installed the same way by the new >>> eclasses + sys-apps/portage which still ignores the new eclasses >>> and tries to pretend being one of them, >>> >>> 3. Twisted dropin.cache files that are installed the same way and use >>> a common eclass. >>> >>> I think in all three cases, we could move it off the profile to >>> eclasses. But I don't think it's worth the effort. >> >> Sure, it's convenient now to just throw some variables in the profile >> and be done with it. But we should also consider potential long-term >> implications. Who knows how big this profile variable will eventually >> grow? Will we have make it an "incremental" variable to make it more >> manageable as Martin Vaeth suggested? What about ebuilds in overlays >> that would like to encapsulate a private COLLISION_IGNORE setting? > > So far, I believe this is mostly a convenience for the migration > period. I would be happy to remove the values that were added for > Python packages as soon as we kill the old eclass.
That sounds reasonable. > Is changing/extending the scope of it in the future a problem? Probably not much of a problem, if any. -- Thanks, Zac
