Hi guys, sys-devel/gcc::repos is only an example but from my side it is a real example.
Currently, Sabayon use our gcc ebuild so it is needed mask gentoo version for rebuild sabayon-stage3 and now it is only possible (like other packages) through file (from sabayon side): /etc/portage/package.mask/00-sabayon.package.mask My idea is permit to define this mask rules under sabayon overlay as profile and/or as targets. Interesting idea is opposite scenario propose by Barsnes about block overlay packages. Thank you to all for feedback about this proposal. G. On Fri, 2018-03-23 at 15:25 +0100, Arve Barsnes wrote: > On 23 March 2018 at 14:27, Rich Freeman <ri...@gentoo.org> wrote: > > It sounds to me that one of the intended behaviors is to tell > > portage > > that for a particular package we want to ignore a particular > > repository entirely. Suppose for example an overlay contains > > misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we > > want > > portage to stick with foo-3 from the overlay. However, if the > > overlay > > adds foo-4, or foo-4.1 we want this installed. A version mask > > would > > not really cover this use case. > > > > IMO this sounds like a useful feature. Having it in profiles could > > probably also be useful in some testing scenarios, such as when > > making > > changes to a large number of packages that are already in the main > > tree (think something analogous to a feature branch in git, where > > the > > master branch continues to advance). > > Unless I'm misunderstanding, this is possible already in > package.mask? > If the mask is not permanent (for testing, as you mention), would > there be any benefit in having it in profile instead? > > Putting misc/foo::gentoo in package.mask works fine either way. > Probably <misc/foo-4::gentoo works as well, for your scenario above. > > I use this for the opposite scenario, I have */*::overlay in > package.mask, and unmask only a particular package in package.unmask, > to avoid bringing in a lot of overlay packages without having a > particular need. > > Arve >
