| 1 |
On 6 September 2013 12:11, Alex Efros <powerman@××××××××.name> wrote: |
| 2 |
|
| 3 |
> |
| 4 |
> # require perl-5.18 |
| 5 |
> =virtual/perl-ExtUtils-CBuilder-0.280.210 |
| 6 |
> =virtual/perl-ExtUtils-ParseXS-3.220.0 |
| 7 |
> =virtual/perl-IO-1.280.0 |
| 8 |
> =virtual/perl-Perl-OSType-1.3.0 |
| 9 |
> =virtual/perl-CPAN-2.0.0 |
| 10 |
> |
| 11 |
|
| 12 |
|
| 13 |
At least in ::gentoo, nothing should be presently pulling in 5.18 in arch~ |
| 14 |
, and everything that does get pulled in should be filed as a bug, because |
| 15 |
if its not filed as a bug and fixed now, it will possibly become become a |
| 16 |
bigger problem when 5.16 becomes the new "arch"/ stable. |
| 17 |
|
| 18 |
Sometimes virtuals get confused and pull in versions of perl instead of |
| 19 |
pulling in perl-core/* , but this is not one of those times I think. |
| 20 |
|
| 21 |
In the cases above, the problem seems because somebody didn't add |
| 22 |
perl-core/* to tree when they added virtual/perl-* to tree, and any |
| 23 |
instance you hit of this, where it is indeed the case that those versions |
| 24 |
are avialable from CPAN, the corresponding perl-core/* should be in tree. |
| 25 |
|
| 26 |
ie: |
| 27 |
|
| 28 |
|| ( =dev-lang/perl-5.18* ~perl-core/CPAN-${PV} ) |
| 29 |
|
| 30 |
If the denormalised version of $PV on exists on CPAN and |
| 31 |
perl-core/WHATEVER-$PV does not exist, thats a bug, and the respective |
| 32 |
package should be added to tree. |
| 33 |
|
| 34 |
If the denormalised version does NOT exist on CPAN, then thats a bug , and |
| 35 |
the virtual/ that implies 5.18 unconditionally in such a case should be |
| 36 |
bugged as something that should be in the 5.18 mask. |
| 37 |
|
| 38 |
|
| 39 |
|
| 40 |
-- |
| 41 |
Kent |
| 42 |
|
| 43 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) |
| 44 |
for ( 9,8,0,7,1,6,5,4,3,2 );" |
Archives