I have have foo-1.2, and foo-1.2-r1. foo-1.2 RDEPENDS on bar-1.0, and foo-1.2-r1 RDEPENDS on bar-2.0, which is masked. I don't want portage to "see" foo-1.2-r1 until bar-2.0 is unmasked [an implicit unmasking], and I don't want to manually [explicitly] mask foo-1.2-r1, either. Is this possible? Nobody in IRC was able to answer this question with an answer other than "no." To demonstrate, using boa and baselayout (baselayout 1.8.0 is masked): boa-0.94.13 + baselayout < 1.8.0 work well. boa-0.94.13 + baselayout == 1.8.0 breaks boa (though it's a minor break, because baselayout changes nogroup to nobody in /etc/groups, and the conf file uses nogroup.) boa-0.94.13-r1 (could) have a new boa.conf that uses nobody. Thus, it would work with 1.8.0+ but not < 1.8.0 SO, the idea for an "implicit mask" came up. This is what I got when I tried it: honker boa # grep -C2 baselayout boa-0.94.13-r1.ebuild RDEPEND="virtual/glibc >=sys-apps/baselayout-1.8.0" src_compile() { honker boa # emerge --pretend boa These are the packages that I would merge, in order. Calculating dependencies \ !!! Error: couldn't find match for ">=sys-apps/baselayout-1.8.0" in net-www/boa-0.94.13-r1 honker boa # emerge --version Portage 2.0.22 honker boa # It's not a big deal, but it *could* make some things quite a bit easier. Then something like 'kde-unstable' could be a meta-package, and unstable kde stuff could just depend/rdepend on that, and portage would be none the wiser. Then, if somebody wants to try it, they just unmask kde-unstable, and *whee*, they get lots of neat stuff. ETc...
still an issue ?
even while the idea is interesting I think it would have a non-trivial performance penalty and might be counter-intuitive (and the masking system is already complex enough).
