Re: [gentoo-dev] Revisiting version-related tree policies

[Kent Fredric]

On Sat, 5 Nov 2016 11:13:35 +0100
Ulrich Mueller <ulm@g.o> 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