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

[Kent Fredric]

On Fri, 4 Nov 2016 10:24:28 +0100
Ulrich Mueller <ulm@g.o> wrote:

> I would assume 9999 to be high enough, even if you use multiples of
> 100 to label the slot. Or do you expect having more than 100 slots for
> Perl?

Well, the desire is for the -r<x> (or similar) part correspond to
something representative of which version of Perl the virtual is an
"underwriter" for.

So it would naturally start at one of the following:

 522, 524, 526
 5022, 5024, 5026

And then you realise upstream are getting crazy and you'll need a
seperate virtual only for 5.22.1, so you'll need

 -r5221

But that's only enough for a prefix for the identifier ... so you'll want -r52210, -r52211, 

and at this point, it very much is getting into the weeds of confusing.

Granted I'm still at "worry about things that aren't actually a problem yet" stage.

Mostly because we're not yet employing this technique until we're sure
its going to be a good idea, and the only place we've *kinda* needed
such a solution is virtual/perl-Test-Simple
( https://bugs.gentoo.org/show_bug.cgi?id=584238#c11 )

The problem however is reduced as follows:

1. Slots are not appropriate, because they can't be concurrently installed
2. versions must indicate an upgrade path to coerce portage to install
   and remove things as needed
3. versions on the virtual themselves must correlate with upstream,
   because we use the virtuals to ensure "X version of Y exists somehow"

and the /desire/ is to have an -r<x> scheme that we could consider
making automated one day.

There's just not a lot of wiggle room, because most of PV is "upstreams
version", and the '-r<x>' part is really the only part we can have some
flexibility with.