Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults

[Michał Górny]

Dnia 2013-08-09, o godz. 23:27:41
Zac Medico <zmedico@g.o> napisał(a):

> On 08/09/2013 02:32 AM, Michał Górny wrote:
> > Hello,
> >
> > Just a quick one.
> >
> > Currently, the two listed variables are set in make.globals (installed
> > by portage ebuild);
> >
> > COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
> > UNINSTALL_IGNORE="/lib/modules/*"
> >
> > COLLISION_IGNORE specifies files that will be ignored by
> > FEATURES=collision-protect when they exist but are not owned by any
> > package. UNINSTALL_IGNORE specifies files that will not be unmerged.
> >
> > By keeping those two in portage, we're basically binding them to
> > version of portage installed. If we need to ignore more files, we need
> > to request our users to upgrade portage.
> >
> > That's why I'm thinking of moving them to profiles/base/make.defaults.
> > From what I've tested, the setting there will override make.globals
> > and therefore the change could be effective from day one, without
> > the need to upgrade portage.
> >
> > I feel like those variables are much alike the QA variables that we
> > keep in the profiles.
> >
> > What do you think?
> >
>
> 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.

-- 
Best regards,
Michał Górny