emerge -pv plone will result in
[ebuild N ] net-zope/zope-3.3.1 6,440 kB
[ebuild N ] net-zope/zope-2.10.7 7,099 kB
[ebuild N ] media-gfx/xv-3.10a-r15 USE="jpeg png tiff" 3,539 kB
[ebuild N ] app-admin/zope-config-0.6 0 kB
[ebuild N ] app-admin/zprod-manager-0.3.3 0 kB
[ebuild N ] dev-python/imaging-1.1.6 USE="X examples -doc -scanner -tk" 426 kB
[ebuild N ] net-zope/plone-3.1.7 12,487 kB
It isn't necessary to install both Zope3 and Zope2, this can be resolved by installing by hand zope2 and then by installing plone, which will result in plone not needing zope3 anymore as it needs "a zope release" and we just installed zope2.
Plone package should prevent zope-config from installing zope3 as plone package itself is already installing zope2.
Steps to Reproduce:
1.emerge -pv plone (and you will see that zope3 will be requested)
3.emerge -pv plone (and you will see that zope3 is not requested anymore)
Too hard to fix by me.
What happens is that some packages ask to emerge a version of net-zope/zope, putting constraints on the version, and some just ask for "any" version of it.
Portage includes both a constrained version and the last allowed version, as they are slotted, and so they can live together.
Removing the slotting could, maybe, fix it. But then you cannot have more then one zope version on your computer.
Adding portage developers to CC, so maybe I could have some guideline.
For now, you can just mask net-zope/zope-3* by adding
>=net-zope/zope-3 in etc/portage/package.mask
The sort of behavior that you want could be implemented in emerge as an 'avoid redundant upgrades' algorithm, so I'll reassign.
If we don't pull in new slots, you'll never get the new versions, and newer versions are typically preferred. So, I think it's better to leave it to individuals to use a local package.mask if they feel that a new version is unnecessary.