1 |
On Sat, Aug 27, 2005 at 01:32:33PM +0200, Fernando J. Pereda wrote: |
2 |
> On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote: |
3 |
> > Not sure about package.mask. I thought that was part of the profile, |
4 |
> > as different profiles might package.mask separately. I know I use it |
5 |
> > in /etc/profile to postpone updates. |
6 |
> |
7 |
> In fact the arch teams use it to mask packages that won't work on a |
8 |
> particular profile/arch. If package.mask is removed from the profiles |
9 |
> directory does it mean we won't be able to do that anymore ? |
10 |
|
11 |
You're masking occurs within the profile itself, not globally. |
12 |
Global masking usually is for introduction of new ebuilds that need |
13 |
testing and shouldn't be hit by normal arch testers (portage early |
14 |
release candidates for example); if you're blocking valgrind on arm |
15 |
(fex), you *should* be blocking it in profiles/default-linux/arm, not |
16 |
profiles/package.mask ;) |
17 |
|
18 |
If it's profile specified files, relax, not targeted :). |
19 |
Strictly after getting the global data out of there, and into a |
20 |
directory reflecting that data's actual role within the repository, |
21 |
and makes sense in a more flexible, non single |
22 |
$PORTDIR+$PORTDIR_OVERlAY environment. |
23 |
|
24 |
Aside from that, see my other email re: the seperate levels of |
25 |
filtering :) |
26 |
~harring |