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. Is changing/extending the scope of it in the future a problem? -- Best regards, Michał Górny
signature.asc
Description: PGP signature
