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? -- Thanks, Zac
