1 |
Dnia 2013-08-09, o godz. 09:47:38 |
2 |
Zac Medico <zmedico@g.o> napisał(a): |
3 |
|
4 |
> On 08/09/2013 02:32 AM, Michał Górny wrote: |
5 |
> > Hello, |
6 |
> > |
7 |
> > Just a quick one. |
8 |
> > |
9 |
> > Currently, the two listed variables are set in make.globals (installed |
10 |
> > by portage ebuild); |
11 |
> > |
12 |
> > COLLISION_IGNORE="/lib/modules/* *.py[co] *\$py.class" |
13 |
> > UNINSTALL_IGNORE="/lib/modules/*" |
14 |
> > |
15 |
> > COLLISION_IGNORE specifies files that will be ignored by |
16 |
> > FEATURES=collision-protect when they exist but are not owned by any |
17 |
> > package. UNINSTALL_IGNORE specifies files that will not be unmerged. |
18 |
> > |
19 |
> > By keeping those two in portage, we're basically binding them to |
20 |
> > version of portage installed. If we need to ignore more files, we need |
21 |
> > to request our users to upgrade portage. |
22 |
> > |
23 |
> > That's why I'm thinking of moving them to profiles/base/make.defaults. |
24 |
> > From what I've tested, the setting there will override make.globals |
25 |
> > and therefore the change could be effective from day one, without |
26 |
> > the need to upgrade portage. |
27 |
> > |
28 |
> > I feel like those variables are much alike the QA variables that we |
29 |
> > keep in the profiles. |
30 |
> > |
31 |
> > What do you think? |
32 |
> |
33 |
> I guess it's fine. I would do it like this in order to respect the |
34 |
> portage default setting: |
35 |
> |
36 |
> COLLISION_IGNORE="${COLLISION_IGNORE} new stuff" |
37 |
|
38 |
Well, the intent was to put the current default in there, and drop it |
39 |
in next version of portage since it is specific to gx86 eclasses |
40 |
and ebuilds. |
41 |
|
42 |
-- |
43 |
Best regards, |
44 |
Michał Górny |