| 1 |
On 08/10/2013 12:48 AM, Michał Górny wrote: |
| 2 |
>> Are we sure that this thing really belongs in the profile, rather than |
| 3 |
>> something that's defined in ebuilds? Or maybe we should have both? |
| 4 |
> |
| 5 |
> Well, AFAICS we have three cases: |
| 6 |
> |
| 7 |
> 1. kernel modules that all are installed to a common location |
| 8 |
> and therefore global collision/uninstall ignore setting works fine, |
| 9 |
> |
| 10 |
> 2. Python compiled files that all are installed the same way by the new |
| 11 |
> eclasses + sys-apps/portage which still ignores the new eclasses |
| 12 |
> and tries to pretend being one of them, |
| 13 |
> |
| 14 |
> 3. Twisted dropin.cache files that are installed the same way and use |
| 15 |
> a common eclass. |
| 16 |
> |
| 17 |
> I think in all three cases, we could move it off the profile to |
| 18 |
> eclasses. But I don't think it's worth the effort. |
| 19 |
|
| 20 |
Sure, it's convenient now to just throw some variables in the profile |
| 21 |
and be done with it. But we should also consider potential long-term |
| 22 |
implications. Who knows how big this profile variable will eventually |
| 23 |
grow? Will we have make it an "incremental" variable to make it more |
| 24 |
manageable as Martin Vaeth suggested? What about ebuilds in overlays |
| 25 |
that would like to encapsulate a private COLLISION_IGNORE setting? |
| 26 |
-- |
| 27 |
Thanks, |
| 28 |
Zac |
Archives