| 1 |
>>>>> On Sun, 6 Nov 2016, Kent Fredric wrote: |
| 2 |
|
| 3 |
> So the strategy that I was considering was to "split" each logical |
| 4 |
> upstream virtual into several pieces: |
| 5 |
|
| 6 |
> virtual/perl-Foo-N to virtual/perl-Foo-N-r99 : "Always pull perl core/*" |
| 7 |
|
| 8 |
> virtual/perl-Foo-N-r52200 to virtual/perl-Foo-N-r52299 : "Always pull perl 5.22 and remove perl-core/*" |
| 9 |
|
| 10 |
> virtual/perl-Foo-N-r52400 to virtual/perl-Foo-N-r52499 : "Always pull perl 5.24 and remove perl-core/*" |
| 11 |
|
| 12 |
I still don't see why you must (ab)use the revision for that. With |
| 13 |
virtuals, the whole PV is at your disposal, so you could append .5.22 |
| 14 |
to it, or even use a suffix like _p522. |
| 15 |
|
| 16 |
The purpose of the revision is really for incremental changes of the |
| 17 |
ebuild within one upstream version. About the only situation where |
| 18 |
using large steps (like 100) in revision numbers is justified is when |
| 19 |
ebuilds in different slots would otherwise collide. |
| 20 |
|
| 21 |
> This idea was hoped to be more predictable than a monolithic virtual |
| 22 |
> that had all those outcomes as possibilities which then caused |
| 23 |
> portage to be confused. |
| 24 |
|
| 25 |
Really, if it is a portage bug then that should be fixed, instead of |
| 26 |
inventing complicated schemes to work around it. |
| 27 |
|
| 28 |
Ulrich |
Archives