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 |