Why? Today dev-python/mod_python-3.0.4-r2, which depends on Apache 2, was declared stable on ~x86. Having "=net-www/apache-2*" in /etc/portage/package.mask and mod_python-2.7.10 (for Apache 1) installed, caused the following error: Calculating world dependencies / !!! all ebuilds that could satisfy ">=net-www/apache-2.0" have been masked. !!! possible candidates are: - net-www/apache-2.0.48 (masked by: package.mask) - net-www/apache-2.0.48-r2 (masked by: package.mask, ~keyword) - net-www/apache-2.0.48-r4 (masked by: package.mask, ~keyword) - net-www/apache-2.0.47 (masked by: package.mask) - net-www/apache-2.0.48-r1 (masked by: package.mask) - net-www/apache-2.0.49 (masked by: package.mask) - net-www/apache-2.0.48-r3 (masked by: package.mask, ~keyword) - net-www/apache-2.0.47-r1 (masked by: package.mask, ~keyword) - net-www/apache-2.0.46 (masked by: package.mask) !!! (dependency required by "dev-python/mod_python-3.0.4-r2" [ebuild]) !!! Problem with ebuild dev-python/mod_python-3.0.4-r2 !!! Possibly a DEPEND/*DEPEND problem. !!! Depgraph creation failed. Now I have to put "=dev-python/mod_python-3*" in package.mask, too. Not a big problem, but which ebuild will be the next? Having lots of ebuilds in package.* files will most likely cause more problems, while this "mask dependency" could be easily and more elegant solved by portage. Reproducible: Always Steps to Reproduce: 1. 2. 3.
The problem then becomes how to make it clear that what portage is about to install is p.masked. We tend to not automate things like that because then people unmask things willy nilly, and especially p.masked packages, they are masked for a reason. The real question is how to make it so that people who want a better tool to do the unmasking ( which I would agree with, it does get annoying especiall with mono ;) ) without giving people who don't know what they are doing a tool to hang themselves with.
Alec, please don't muddle that. I want to mask implicitly, which would be a nice feature to deal with slotted packages and their dependecies, when you don't want to have the stable slot X+1 package installed. I don't want to unmask implitly - or "willy nilly" as you say.
This... likely ain't going to happen. If someone horks the tree by masking a required dependency, we slap them. Detecting, backtracking, and lieing to the user that a package isn't available cause one of it's deps is masked doesn't seem right... Re-open if you disagree/have an approach to this that can be sanely implemented :)