>>>>> On Sun, 6 Nov 2016, Kent Fredric wrote:

> So the strategy that I was considering was to "split" each logical
> upstream virtual into several pieces:

>   virtual/perl-Foo-N  to virtual/perl-Foo-N-r99 : "Always pull perl core/*"

>   virtual/perl-Foo-N-r52200 to virtual/perl-Foo-N-r52299 : "Always pull perl 5.22 and remove perl-core/*"

>   virtual/perl-Foo-N-r52400 to virtual/perl-Foo-N-r52499 : "Always pull perl 5.24 and remove perl-core/*"

I still don't see why you must (ab)use the revision for that. With
virtuals, the whole PV is at your disposal, so you could append .5.22
to it, or even use a suffix like _p522.

The purpose of the revision is really for incremental changes of the
ebuild within one upstream version. About the only situation where
using large steps (like 100) in revision numbers is justified is when
ebuilds in different slots would otherwise collide.

> This idea was hoped to be more predictable than a monolithic virtual
> that had all those outcomes as possibilities which then caused
> portage to be confused.

Really, if it is a portage bug then that should be fixed, instead of
inventing complicated schemes to work around it.

Ulrich