Gentoo Archives: gentoo-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-dev@l.g.o, "Michał Górny" <mgorny@g.o>
Subject: Re: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults
Date: Sat, 10 Aug 2013 06:27:51
Message-Id: 5205DD5D.9080602@gentoo.org
In Reply to: [gentoo-dev] [RFC] Moving COLLISION_IGNORE (and UNINSTALL_IGNORE?) to profiles/*/make.defaults by "Michał Górny"
1 On 08/09/2013 02:32 AM, Michał Górny wrote:
2 > Hello,
3 >
4 > Just a quick one.
5 >
6 > Currently, the two listed variables are set in make.globals (installed
7 > by portage ebuild);
8 >
9 > COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class"
10 > UNINSTALL_IGNORE="/lib/modules/*"
11 >
12 > COLLISION_IGNORE specifies files that will be ignored by
13 > FEATURES=collision-protect when they exist but are not owned by any
14 > package. UNINSTALL_IGNORE specifies files that will not be unmerged.
15 >
16 > By keeping those two in portage, we're basically binding them to
17 > version of portage installed. If we need to ignore more files, we need
18 > to request our users to upgrade portage.
19 >
20 > That's why I'm thinking of moving them to profiles/base/make.defaults.
21 > From what I've tested, the setting there will override make.globals
22 > and therefore the change could be effective from day one, without
23 > the need to upgrade portage.
24 >
25 > I feel like those variables are much alike the QA variables that we
26 > keep in the profiles.
27 >
28 > What do you think?
29 >
30
31 Are we sure that this thing really belongs in the profile, rather than
32 something that's defined in ebuilds? Or maybe we should have both?
33
34 If ebuild devs are forced to use the profile for this, then that global
35 variable could see a lot of growth in the long-term. OTOH, if it's
36 defined at the ebuild level, then it keeps the info more encapsulated,
37 and that may be better particularly for overlay ebuilds.
38 --
39 Thanks,
40 Zac

Replies