1 |
Hi guys, |
2 |
|
3 |
sys-devel/gcc::repos is only an example but from my side it is a real |
4 |
example. |
5 |
|
6 |
Currently, Sabayon use our gcc ebuild so it is needed mask gentoo |
7 |
version for rebuild sabayon-stage3 and now it is only possible (like |
8 |
other packages) through file (from sabayon side): |
9 |
|
10 |
/etc/portage/package.mask/00-sabayon.package.mask |
11 |
|
12 |
My idea is permit to define this mask rules under sabayon overlay as |
13 |
profile and/or as targets. |
14 |
|
15 |
Interesting idea is opposite scenario propose by Barsnes about block |
16 |
overlay packages. |
17 |
|
18 |
Thank you to all for feedback about this proposal. |
19 |
|
20 |
G. |
21 |
|
22 |
|
23 |
On Fri, 2018-03-23 at 15:25 +0100, Arve Barsnes wrote: |
24 |
> On 23 March 2018 at 14:27, Rich Freeman <rich0@g.o> wrote: |
25 |
> > It sounds to me that one of the intended behaviors is to tell |
26 |
> > portage |
27 |
> > that for a particular package we want to ignore a particular |
28 |
> > repository entirely. Suppose for example an overlay contains |
29 |
> > misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we |
30 |
> > want |
31 |
> > portage to stick with foo-3 from the overlay. However, if the |
32 |
> > overlay |
33 |
> > adds foo-4, or foo-4.1 we want this installed. A version mask |
34 |
> > would |
35 |
> > not really cover this use case. |
36 |
> > |
37 |
> > IMO this sounds like a useful feature. Having it in profiles could |
38 |
> > probably also be useful in some testing scenarios, such as when |
39 |
> > making |
40 |
> > changes to a large number of packages that are already in the main |
41 |
> > tree (think something analogous to a feature branch in git, where |
42 |
> > the |
43 |
> > master branch continues to advance). |
44 |
> |
45 |
> Unless I'm misunderstanding, this is possible already in |
46 |
> package.mask? |
47 |
> If the mask is not permanent (for testing, as you mention), would |
48 |
> there be any benefit in having it in profile instead? |
49 |
> |
50 |
> Putting misc/foo::gentoo in package.mask works fine either way. |
51 |
> Probably <misc/foo-4::gentoo works as well, for your scenario above. |
52 |
> |
53 |
> I use this for the opposite scenario, I have */*::overlay in |
54 |
> package.mask, and unmask only a particular package in package.unmask, |
55 |
> to avoid bringing in a lot of overlay packages without having a |
56 |
> particular need. |
57 |
> |
58 |
> Arve |
59 |
> |