On Fri, 4 Nov 2016 10:24:28 +0100 Ulrich Mueller <u...@gentoo.org> 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.
pgp2wxLp58yzJ.pgp
Description: OpenPGP digital signature
