Bug 631842 – dev-lang/perl-5.26 attempted force-install on stable due to virtual/perl-Time-HiRes-1.974.100-r1

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description jorgicio 2017-09-23 14:54:21 UTC]

Hi!

Everytime I want to do a @world, the perl-virtual-related packages force to upgrade to perl 5.26.

All versions installed are stable (not ~arch). Also, any of them depend on perl-5.24 too, but it forces to upgrade to 5.26.

May those conflict packages be fixed in the dependencies? They say the 5.26 goes first than 5.24, even with the "||" operand (which implies it may require both 5.24 or 5.26).

I'll attach the file with the full log (with --verbose-conflicts).

Thanks.

Reproducible: Always

[Comment 1 jorgicio 2017-09-23 14:54:45 UTC]

Created attachment 496170 [details]
The log

[Comment 2 jorgicio 2017-09-23 14:55:22 UTC]

Created attachment 496172 [details]
emerge --info

[Comment 3 Kent Fredric (IRC: kent\n) (RETIRED) 2017-09-23 15:08:54 UTC]

Sorry. Getting onto this asap, not sure what's wrong.

Firstly:

> May those conflict packages be fixed in the dependencies? They say the 5.26 
> goes first than 5.24, even with the "||" operand (which implies it may require 
> both 5.24 or 5.26).

The || ( ) should be fine, as long as one of them are satisfied. So I'll have to go through the log and see if I missed something.


This is the "suspect" set:

  virtual/perl-CPAN-Meta-YAML-0.18.0-r2:0/0::gentoo, installed)

 || ( =dev-lang/perl-5.26* =dev-lang/perl-5.24* ~perl-core/${PN#perl-}-${PV} )

Fine.

  virtual/perl-Text-ParseWords-3.300.0-r3:0/0::gentoo, installed)

|| ( =dev-lang/perl-5.26* =dev-lang/perl-5.24* ~perl-core/${PN#perl-}-${PV} )

Fine.

  virtual/perl-ExtUtils-Install-2.40.0-r3:0/0::gentoo, installed)

|| ( =dev-lang/perl-5.26* =dev-lang/perl-5.24* ~perl-core/${PN#perl-}-${PV} )

Fine.

  virtual/perl-Time-HiRes-1.974.100-r1:0/0::gentoo, installed)

|| ( =dev-lang/perl-5.26* =dev-lang/perl-5.24.3* ~perl-core/${PN#perl-}-${PV} )

This might be where its getting confused: This should be upgrading you to perl 5.24.3 
However, that version is ~arch only. So why you have that version of perl-Time-HiRes

  virtual/perl-ExtUtils-Manifest-1.700.0-r4:0/0::gentoo, installed)

|| ( =dev-lang/perl-5.26* =dev-lang/perl-5.24* ~perl-core/${PN#perl-}-${PV} )

Fine.

  virtual/perl-ExtUtils-CBuilder-0.280.225-r2:0/0::gentoo, installed)

|| ( =dev-lang/perl-5.26* =dev-lang/perl-5.24* ~perl-core/${PN#perl-}-${PV} )

Fine.

[Comment 4 jorgicio 2017-09-23 15:12:28 UTC]

Fine, I have that version of  perl-Time-HiRes because my entire system is ~arch, but I left those packages as arch. But I'll fix it then.
But the issue is still there.

[Comment 5 Kent Fredric (IRC: kent\n) (RETIRED) 2017-09-23 15:21:21 UTC]

(In reply to jorgicio from comment #4)
> Fine, I have that version of  perl-Time-HiRes because my entire system is
> ~arch, but I left those packages as arch. But I'll fix it then.
> But the issue is still there.

Its likely portage getting confused. 

As that version ( and ones like it ) only can be satisfied by a keyword level higher than you have, it might try to take you all the way.

Mixing ~arch and arch, while feasible, has a lot of problems.

But I otherwise can't explain why its doing what its doing, if you have 5.24.1-r2 installed, all constructs of : 


|| ( =dev-lang/perl-5.26* =dev-lang/perl-5.24* ~perl-core/${PN#perl-}-${PV} )

Should be satisfied by that.

Perl 5.24.3 shipped an updated Time-HiRes version, which is why that specific version now pulls that.

usr/bin/corelist -a Time::HiRes | grep 1.9741
  v5.24.3    1.9741    
  v5.25.8    1.9741    
  v5.25.9    1.9741    
  v5.25.10   1.9741    
  v5.25.11   1.9741    
  v5.25.12   1.9741    
  v5.26.0    1.9741    
  v5.26.1    1.9741    
  v5.27.0    1.9741    
  v5.27.1    1.9741

[Comment 6 jorgicio 2017-09-23 15:21:46 UTC]

I found the solution: just downgrade the package you mentioned fixes this issue.
Sorry. My bad.

Thanks.

[Comment 7 Kent Fredric (IRC: kent\n) (RETIRED) 2017-09-23 15:26:17 UTC]

Also, if you see something like this again, can you retry with : 

   --autounmask-keep-masks=y

Would be good to see what portage is doing in that regards :)

But glad your issue is fixed, I was panicking I'd missed something in the 70-different-things that change every release :D 


Marking as "INVALID" as this seems like "Userside bad configuration + portage is typically muddy about weird configuration and nobody knows how to unmuddy it" :D