Dnia 2013-08-09, o godz. 23:27:41 Zac Medico <[email protected]> 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
signature.asc
Description: PGP signature
