On Sat, 5 Nov 2016 11:13:35 +0100 Ulrich Mueller <u...@gentoo.org> wrote:
> revision component must not be used for upstream versions: The problem is we have *2* upstream versions. virtual/perl-Foo-N Maps to perl-core/Foo-N And dev-lang/perl-Y ( for possibly more than one value of Y ) And Y does not equal N Presently, this is "not a problem", because there is only 1 of each "N" for virtual/perl-Foo-N And it maps with this horrible magic of || ( =dev-lang/perl-Y4* =dev-lang/perl-Y3* =dev-lang/perl-Y2* ~perl-core/Foo-N ) !<perl-core/Foo-N !>perl-core/Foo-N-r999 Which is "logically correct", however, as seen in bug #584238[1], portage does not always do the right thing, and it makes a real mess of things having one package virtualising multiple different keywords. ( I had to get into graphing tools to work out what the hell was actually happening ) *especially* in cases where we need to indicate an "upstream merge in a virtual" as with 584238 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/*" Which allows us to control which outcome a user gets by keeping keywords consistent across the board, as we'd stabilize/keyword all '-r522**' with perl 5.22 virtual/perl-Foo-N to virtual/perl-Foo-N-r99 would thus be "Getting multiprovided things at newer versions than is available in your shipped perl", and that -r range would only be stabilized to fast-track security issues or to provide those versions for dependents before the respective perl is stabilized ( that is, the fallback to perl-core is done with maximum reluctance ) 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. ( I hope this explanation is more clear than the last one, but its OK if you're still confused, it took me a few weeks to get my head around it the first time, but I implore you to read the related bug and pay careful attention to its attached images ) 1: https://bugs.gentoo.org/show_bug.cgi?id=584238
pgpUIseOoq5LQ.pgp
Description: OpenPGP digital signature
