Re: [gentoo-user] preparing for profile switch -- major problem

[Daniel Frey]

On 12/09/17 03:23, John Covici wrote:
> On Sat, 09 Dec 2017 03:51:03 -0500,
> Alan McKinnon wrote:
>>
>> On 08/12/2017 21:12, John Covici wrote:
>>> On Fri, 08 Dec 2017 11:42:16 -0500,
>>> Alan McKinnon wrote:
>>>>
>>>> On 07/12/2017 17:46, John Covici wrote:
>>>>> On Thu, 07 Dec 2017 09:37:56 -0500,
>>>>> Alan McKinnon wrote:
>>>>>>
>>>>>> On 07/12/2017 07:44, John Covici wrote:
>>>>>>> Hi. In preparing for the profile switch and the emerge -e world, I
>>
>>
>> [snip]
>>
>>
>>>> No, I don't think you should revert the profile change. I understood
>>>> from your mail than you had not done that yet, and typed accordingly.
>>>>
>>>> I think Michael is on the right track with backtrack - set it to
>>>> something very high like 1000, see if that gets to a solution.
>>>
>>>
>>> I did switch back, but the only way I could do a "successful" update
>>> was to mask off 5.26 and then it skipped the update and would have
>>> been successful.  If I switch to the new profile, I can do nothing as
>>> far as perl goes.  I will show the output of just trying to emerge
>>> below, it seems there were many many packages still requiring 5.24.
>>
>> No, that's not right. The tree is consistent and portage can figure out
>> how to get from perl-5.24 to perl-5.26
>>
>> You probably have a difference locally, I would search through
>> /etc/portage looking for entries that mask some perl modules and peg
>> them to 5.24 versions.
>>
>> Failing that, maybe you have a package installed that depends on a 5.24
>> version of some module and this is the ripple effect
>>
>> Perhaps run emerge with "--verbose-conflicts" and also "emerge -e world"
>> and post the results
>>
>>
>>> This is with the new profile and backtrack set to 500.
>>>
>>>   instances within a single package slot have been pulled
>>>   !!! into the dependency graph, resulting in a slot conflict:
>>>
>>> dev-lang/perl:0
>>>
>>>    (dev-lang/perl-5.26.1-r1:0/5.26::gentoo, ebuild scheduled for merge)
>>>    pulled in by
>>>        =dev-lang/perl-5.26* required by
>>>    (virtual/perl-ExtUtils-Manifest-1.700.0-r4:0/0::gentoo, installed)
>>>        ^              ^^^^^
>>> 	     dev-lang/perl (Argument)
>>> 		    (and 13 more with the same problems)
>>>
>>>    (dev-lang/perl-5.24.3:0/5.24::gentoo, installed) pulled in by
>>>        =dev-lang/perl-5.24* required by
>>>        (virtual/perl-Term-ANSIColor-4.40.0-r1:0/0::gentoo, installed)
>>> 	     ^              ^^^^^
>>> 		    dev-lang/perl:0/5.24= required by
>>>        (dev-perl/XML-Twig-3.520.0:0/0::gentoo, installed)
>>> 	                  ^^^^^^^^
>>> 				       (and 260 more with the same problems)
>>>
>>> NOTE: Use the '--verbose-conflicts' option to display parents omitted
>>> above
>>>
>>> It may be possible to solve this problem by using package.mask to
>>> prevent one of those packages from being selected. However, it is also
>>> possible that conflicting dependencies exist such that they are
>>> impossible to satisfy simultaneously.  If such a conflict exists in
>>> the dependencies of two different packages, then those packages can
>>> not be installed simultaneously.
>>>
>>> For more information, see MASKED PACKAGES section in the emerge man
>>> page or refer to the Gentoo Handbook.
>
> hmmm, nothing masked as far as perl modules,  I will look at
> verbose-conflicts and maybe write down all those modules and start
> unmerging and see if eventually portage can figure out something -- I
> don't really want to  do that,  however I will look at the conflicts
> and see what I can find.
>
>

I had a lot of problems with the perl updates as well, and could not get 
it to resolve. I wasted over an hour trying to resolve it (my poor 
Celeron would take 5-10 minutes trying to calculate dependencies, and I 
had to do this 6-7 times.)

Note, what I did worked for me and may not work for you, so use this 
advice at your own risk: I emerged the new perl with --nodeps, and 
invoked `perl-cleaner all` to fix the mess afterwards. It had everything 
resolved in < 10 minutes. I didn't suffer any system breakage from using 
the sledgehammer approach, but others may not be so lucky... so, as I 
said, try it at your own risk.

Dan