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

[Marc Joliet]

Am Sonntag, 10. Dezember 2017, 13:36:19 CET schrieb Kent Fredric:
> as a sort
> of bodge to compensate for the fact portage has no working "provides"
> feature

I'd just like to point out that, to the best of my knowledge, portage actually 
switched *from* a "provides" model *to* the virtual system we use today.  
(This was more than a decade ago, before I started using Gentoo.  I remember 
this because I vaguely recall seeing repoman and/or portage warnings about 
deprecated use of PROVIDES or some such in overlay ebuilds.)

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup


signature.asc
Description: This is a digitally signed message part.

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

[John Covici]

On Sun, 10 Dec 2017 07:36:19 -0500,
Kent Fredric wrote:
> 
> [1  ]
> On Sun, 10 Dec 2017 02:17:09 -0500
> John Covici  wrote:
> 
> > OK, thanks, I think I will try that.
> 
> The problem you're facing is that you masked dev-lang/perl, but not any
> virtual/perl-* or perl-core/-* to compensate.
> 
> These 3 components work in concert like a single component, as a sort
> of bodge to compensate for the fact portage has no working "provides" feature,
> and to compensate for the dependency-system missmatch between how
> Gentoo works and how CPAN works.
> 
> Theres' no easy way of fixing this atm, but the short of it is if you're using
> an ~arch dev-lang/perl, you should be using an ~arch virtual/perl-*,
> and if you're using an "arch" dev-lang/perl, you should be using only
> "arch" versions of virtual/perl-*
> 
> Once you do this, portage may still scream at you, because portage is
> very much optimised for upgrading, and it tends to think downgrading is
> an error.
> 
> So once you get all your masks/keyword changes in place, you should do:
> 
>   emerge -C virtual/perl-*
>   emerge -C perl-core/*
> 
> (or something to that effect)
> 
> This looks scary, but generally isn't, because you're not actually removing
> anything with this, just juggling a few balls and making only older
> versions of certain things available ( as they're alls shipped in
> dev-lang/perl )
> 
> And then after you do this, portage is more likely to be persuadable
> into doing the right thing.
> 
> You can additionally abuse my tool, gentoo-perl-helpers for doing some of 
> this,
> and some of the steps I've described are automated because they're just
> that safe and useful.
> 
> https://wiki.gentoo.org/wiki/Perl#app-admin.2Fgentoo-perl-helpers
> 
> 
> After putting the right masks in place, do:
> 
>   gentoo-perl gen-upgrade-sets 5.26 5.24
> 
> And if you're really lucky, the sets it generates will work the first time :)
> 
> ( I actually tested this scenario when developing it, but its still an
> undocumented use on purpose )

OK, so I am doing the usual update of world and portage figured out
about hundreds of perl modules and even  thepython setuptools, so I
will do that and then think about doing the -e world, but I may wait
awhile on that -- this one will take at least 48 hours.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

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

[John Covici]

On Sun, 10 Dec 2017 08:13:09 -0500,
Alan McKinnon wrote:
> 
> On 10/12/2017 14:54, John Covici wrote:
> > On Sun, 10 Dec 2017 07:36:19 -0500,
> > Kent Fredric wrote:
> >>
> >> [1  ]
> >> On Sun, 10 Dec 2017 02:17:09 -0500
> >> John Covici  wrote:
> >>
> >>> OK, thanks, I think I will try that.
> >>
> >> The problem you're facing is that you masked dev-lang/perl, but not any
> >> virtual/perl-* or perl-core/-* to compensate.
> >>
> >> These 3 components work in concert like a single component, as a sort
> >> of bodge to compensate for the fact portage has no working "provides" 
> >> feature,
> >> and to compensate for the dependency-system missmatch between how
> >> Gentoo works and how CPAN works.
> >>
> >> Theres' no easy way of fixing this atm, but the short of it is if you're 
> >> using
> >> an ~arch dev-lang/perl, you should be using an ~arch virtual/perl-*,
> >> and if you're using an "arch" dev-lang/perl, you should be using only
> >> "arch" versions of virtual/perl-*
> >>
> >> Once you do this, portage may still scream at you, because portage is
> >> very much optimised for upgrading, and it tends to think downgrading is
> >> an error.
> >>
> >> So once you get all your masks/keyword changes in place, you should do:
> >>
> >>   emerge -C virtual/perl-*
> >>   emerge -C perl-core/*
> >>
> >> (or something to that effect)
> >>
> >> This looks scary, but generally isn't, because you're not actually removing
> >> anything with this, just juggling a few balls and making only older
> >> versions of certain things available ( as they're alls shipped in
> >> dev-lang/perl )
> >>
> >> And then after you do this, portage is more likely to be persuadable
> >> into doing the right thing.
> >>
> >> You can additionally abuse my tool, gentoo-perl-helpers for doing some of 
> >> this,
> >> and some of the steps I've described are automated because they're just
> >> that safe and useful.
> >>
> >> https://wiki.gentoo.org/wiki/Perl#app-admin.2Fgentoo-perl-helpers
> >>
> >>
> >> After putting the right masks in place, do:
> >>
> >>gentoo-perl gen-upgrade-sets 5.26 5.24
> >>
> >> And if you're really lucky, the sets it generates will work the first time 
> >> :)
> >>
> >> ( I actually tested this scenario when developing it, but its still an
> >> undocumented use on purpose )
> >>
> >> GLHF.
> > 
> > I went ahead and did the upgrade which worked, but the emerge from
> > perl-cleaner --all did not.  I am using ~amd64 and have done so for
> > years, so I don't think I need to maks off anything.  I seem now to be
> > stuck with dev-python/setuptools, so I am now trying to figure out why
> > I can't emerge that -- it was triggered by the perl-cleaner --all .
> > 
> 
> How recent is your tree?
> 
> I had issues with setuptools doing the first run through the 17.0
> upgrade. I never looked into it too closely, I used --keep-going, but
> setuptools seemed to think I had a useable python-3.4
> 
> After the first run through emerge -e world, nuking-python-3.4 and
> re-syncing, setuptols worked normally again.
> 
> YMMV of course where you are

My tree maybe 30 days old or thereabouts.  I could not run  the emerge
from perl-cleaner because of setup-tools problems.  I will see what
happens if I run a regular update, but I hate to do that if I am going
to do an -e world.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

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

[Kent Fredric]

On Sun, 10 Dec 2017 07:54:59 -0500
John Covici  wrote:

> I am using ~amd64 and have done so for
> years, so I don't think I need to maks off anything. 

Sorry, I may have gotten my wires crossed.

The impression I got was you were trying to stick with perl 5.24

The point is *if* you're sticking with perl 5.24 ( which is current
stable ) then by design, you need the set of virtuals that specify perl
5.24.

If you try to use "~amd64" virtuals with an "amd64" perl, portage will
try to install the newest versions of those virtuals, which in turn
force installing perl 5.26

Hence, you need to use a paired combination of dev-lang/perl and
virtuals.

Just the mechanism by which we make this pairing happens is via
stability levels.

Hence, if you wanted to use Perl 5.24, you would need to do more than
merely mask perl 5.26, you would need to mask the virtuals that tell
portage to install perl 5.26 as well.



pgplYBN3na4dI.pgp
Description: OpenPGP digital signature

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

[Alan McKinnon]

On 10/12/2017 14:54, John Covici wrote:
> On Sun, 10 Dec 2017 07:36:19 -0500,
> Kent Fredric wrote:
>>
>> [1  ]
>> On Sun, 10 Dec 2017 02:17:09 -0500
>> John Covici  wrote:
>>
>>> OK, thanks, I think I will try that.
>>
>> The problem you're facing is that you masked dev-lang/perl, but not any
>> virtual/perl-* or perl-core/-* to compensate.
>>
>> These 3 components work in concert like a single component, as a sort
>> of bodge to compensate for the fact portage has no working "provides" 
>> feature,
>> and to compensate for the dependency-system missmatch between how
>> Gentoo works and how CPAN works.
>>
>> Theres' no easy way of fixing this atm, but the short of it is if you're 
>> using
>> an ~arch dev-lang/perl, you should be using an ~arch virtual/perl-*,
>> and if you're using an "arch" dev-lang/perl, you should be using only
>> "arch" versions of virtual/perl-*
>>
>> Once you do this, portage may still scream at you, because portage is
>> very much optimised for upgrading, and it tends to think downgrading is
>> an error.
>>
>> So once you get all your masks/keyword changes in place, you should do:
>>
>>   emerge -C virtual/perl-*
>>   emerge -C perl-core/*
>>
>> (or something to that effect)
>>
>> This looks scary, but generally isn't, because you're not actually removing
>> anything with this, just juggling a few balls and making only older
>> versions of certain things available ( as they're alls shipped in
>> dev-lang/perl )
>>
>> And then after you do this, portage is more likely to be persuadable
>> into doing the right thing.
>>
>> You can additionally abuse my tool, gentoo-perl-helpers for doing some of 
>> this,
>> and some of the steps I've described are automated because they're just
>> that safe and useful.
>>
>> https://wiki.gentoo.org/wiki/Perl#app-admin.2Fgentoo-perl-helpers
>>
>>
>> After putting the right masks in place, do:
>>
>>  gentoo-perl gen-upgrade-sets 5.26 5.24
>>
>> And if you're really lucky, the sets it generates will work the first time :)
>>
>> ( I actually tested this scenario when developing it, but its still an
>> undocumented use on purpose )
>>
>> GLHF.
> 
> I went ahead and did the upgrade which worked, but the emerge from
> perl-cleaner --all did not.  I am using ~amd64 and have done so for
> years, so I don't think I need to maks off anything.  I seem now to be
> stuck with dev-python/setuptools, so I am now trying to figure out why
> I can't emerge that -- it was triggered by the perl-cleaner --all .
> 

How recent is your tree?

I had issues with setuptools doing the first run through the 17.0
upgrade. I never looked into it too closely, I used --keep-going, but
setuptools seemed to think I had a useable python-3.4

After the first run through emerge -e world, nuking-python-3.4 and
re-syncing, setuptols worked normally again.

YMMV of course where you are
-- 
Alan McKinnon
alan.mckin...@gmail.com

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

[John Covici]

On Sun, 10 Dec 2017 07:36:19 -0500,
Kent Fredric wrote:
> 
> [1  ]
> On Sun, 10 Dec 2017 02:17:09 -0500
> John Covici  wrote:
> 
> > OK, thanks, I think I will try that.
> 
> The problem you're facing is that you masked dev-lang/perl, but not any
> virtual/perl-* or perl-core/-* to compensate.
> 
> These 3 components work in concert like a single component, as a sort
> of bodge to compensate for the fact portage has no working "provides" feature,
> and to compensate for the dependency-system missmatch between how
> Gentoo works and how CPAN works.
> 
> Theres' no easy way of fixing this atm, but the short of it is if you're using
> an ~arch dev-lang/perl, you should be using an ~arch virtual/perl-*,
> and if you're using an "arch" dev-lang/perl, you should be using only
> "arch" versions of virtual/perl-*
> 
> Once you do this, portage may still scream at you, because portage is
> very much optimised for upgrading, and it tends to think downgrading is
> an error.
> 
> So once you get all your masks/keyword changes in place, you should do:
> 
>   emerge -C virtual/perl-*
>   emerge -C perl-core/*
> 
> (or something to that effect)
> 
> This looks scary, but generally isn't, because you're not actually removing
> anything with this, just juggling a few balls and making only older
> versions of certain things available ( as they're alls shipped in
> dev-lang/perl )
> 
> And then after you do this, portage is more likely to be persuadable
> into doing the right thing.
> 
> You can additionally abuse my tool, gentoo-perl-helpers for doing some of 
> this,
> and some of the steps I've described are automated because they're just
> that safe and useful.
> 
> https://wiki.gentoo.org/wiki/Perl#app-admin.2Fgentoo-perl-helpers
> 
> 
> After putting the right masks in place, do:
> 
>   gentoo-perl gen-upgrade-sets 5.26 5.24
> 
> And if you're really lucky, the sets it generates will work the first time :)
> 
> ( I actually tested this scenario when developing it, but its still an
> undocumented use on purpose )
> 
> GLHF.

I went ahead and did the upgrade which worked, but the emerge from
perl-cleaner --all did not.  I am using ~amd64 and have done so for
years, so I don't think I need to maks off anything.  I seem now to be
stuck with dev-python/setuptools, so I am now trying to figure out why
I can't emerge that -- it was triggered by the perl-cleaner --all .

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

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

[Kent Fredric]

On Sun, 10 Dec 2017 02:17:09 -0500
John Covici  wrote:

> OK, thanks, I think I will try that.

The problem you're facing is that you masked dev-lang/perl, but not any
virtual/perl-* or perl-core/-* to compensate.

These 3 components work in concert like a single component, as a sort
of bodge to compensate for the fact portage has no working "provides" feature,
and to compensate for the dependency-system missmatch between how
Gentoo works and how CPAN works.

Theres' no easy way of fixing this atm, but the short of it is if you're using
an ~arch dev-lang/perl, you should be using an ~arch virtual/perl-*,
and if you're using an "arch" dev-lang/perl, you should be using only
"arch" versions of virtual/perl-*

Once you do this, portage may still scream at you, because portage is
very much optimised for upgrading, and it tends to think downgrading is
an error.

So once you get all your masks/keyword changes in place, you should do:

  emerge -C virtual/perl-*
  emerge -C perl-core/*

(or something to that effect)

This looks scary, but generally isn't, because you're not actually removing
anything with this, just juggling a few balls and making only older
versions of certain things available ( as they're alls shipped in
dev-lang/perl )

And then after you do this, portage is more likely to be persuadable
into doing the right thing.

You can additionally abuse my tool, gentoo-perl-helpers for doing some of this,
and some of the steps I've described are automated because they're just
that safe and useful.

https://wiki.gentoo.org/wiki/Perl#app-admin.2Fgentoo-perl-helpers


After putting the right masks in place, do:

gentoo-perl gen-upgrade-sets 5.26 5.24

And if you're really lucky, the sets it generates will work the first time :)

( I actually tested this scenario when developing it, but its still an
undocumented use on purpose )

GLHF.


pgp7qA19Q_4VT.pgp
Description: OpenPGP digital signature

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

[John Covici]

On Sat, 09 Dec 2017 18:20:40 -0500,
Daniel Frey wrote:
> 
> On 12/09/17 08:18, John Covici wrote:
> > On Sat, 09 Dec 2017 10:28:25 -0500,
> > Daniel Frey wrote:
> >> 
> >> 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.
> > 
> > I was thinking of just that myself, I may try that  later today.  I am
> > using zfs, and do snapshots frequently, so it might be possible to get
> > back if things are a disaster, but it might work at that.   Did you
> > emerge perl again without the --nodeps afterwards to make sure?
> > 
> > 
> 
> Well, due to the long compile times I was trying to get the
> dependencies resolved so I could run `emerge -auDNe world
> --exclude sys-devel/gcc --exclude sys-devel/llvm --exclude
> sys-devel/libtool --exclude sys-devel/binutils --exclude
> sys-libs/glibc --keep-going world` so it would recompile
> everything and update as it went along. (I had already built the
> excluded packages under the new profile with gcc6.)
> 
> While I didn't remerge perl immediately after, it was included in
> the rebuild process of --emptytree.
> 
> And it was successful! I only had perl blocking everything, so
> once I sledgeammered that update, it was able to calculate its
> dependency list, and it rebuilt all 500 installed packages (well,
> less the ones I excluded) successfully - no failed packages or
> anything, while upgrading as needed. It did take almost 30 hours
> though.
> 
> When trying to get perl blockers to resolve I even tried
> --backtrack=200 and it still failed. That was try 5 or 6 and at
> that point I was getting annoyed and tried the sledgehammer
> technique.

OK, thanks, I think I will try that.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

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

[Peter Humphrey]

On Saturday, 9 December 2017 23:20:40 GMT Daniel Frey wrote:

> I was trying to get the dependencies resolved so I could run
> `emerge - auDNe world ...

Really? Specifying -e overrules -uDN and makes them superfluous. Why would 
you want to do that?

-- 
Regards,
Peter.

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

[Daniel Frey]

On 12/09/17 08:18, John Covici wrote:

On Sat, 09 Dec 2017 10:28:25 -0500,
Daniel Frey wrote:


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.


I was thinking of just that myself, I may try that  later today.  I am
using zfs, and do snapshots frequently, so it might be possible to get
back if things are a disaster, but it might work at that.   Did you
emerge perl again without the --nodeps afterwards to make sure?




Well, due to the long compile times I was trying to get the dependencies 
resolved so I could run `emerge -auDNe world --exclude sys-devel/gcc 
--exclude sys-devel/llvm --exclude sys-devel/libtool --exclude 
sys-devel/binutils --exclude sys-libs/glibc --keep-going world` so it 
would recompile everything and update as it went along. (I had already 
built the excluded packages under the new profile with gcc6.)


While I didn't remerge perl immediately after, it was included in the 
rebuild process of --emptytree.


And it was successful! I only had perl blocking everything, so once I 
sledgeammered that update, it was able to calculate its dependency list, 
and it rebuilt all 500 installed packages (well, less the ones I 
excluded) successfully - no failed packages or anything, while upgrading 
as needed. It did take almost 30 hours though.


When trying to get perl blockers to resolve I even tried --backtrack=200 
and it still failed. That was try 5 or 6 and at that point I was getting 
annoyed and tried the sledgehammer technique.


Dan

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

[Alan McKinnon]

On 09/12/2017 17:28, Daniel Frey wrote:
>> 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.

that is a very clever solution, one that never occured to me. Ought to
be at the end of the wiki page, titled "when all else fails, you can
always do it this way"

It's good advice of last resort, really


-- 
Alan McKinnon
alan.mckin...@gmail.com

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

[John Covici]

On Sat, 09 Dec 2017 10:28:25 -0500,
Daniel Frey wrote:
> 
> 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.

I was thinking of just that myself, I may try that  later today.  I am
using zfs, and do snapshots frequently, so it might be possible to get
back if things are a disaster, but it might work at that.   Did you
emerge perl again without the --nodeps afterwards to make sure?


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

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

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

[John Covici]

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.


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

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

[Alan McKinnon]

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.
> 
> 
> 
> 


-- 
Alan McKinnon
alan.mckin...@gmail.com

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

[John Covici]

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
> >>> have run into a serious problem with perl.  I think I saw on this list
> >>> where perl 5.26 was going to have problems -- maybe until it is
> >>> stabilized -- but if I mask it off,  I get the following:
> >>
> >> Unmask the latest perl and update world with the old profile
> >>
> >> This will go smoothly as the perl team did an excellent job making sure
> >> everything perl-ish in the tree works in concert with everything else.
> >> However I do recall that trying to do it with a partial world update
> >> didn't work - too many affected packages, so trying just perl + deps did
> >> not work. Rather do a normal world update.
> >>
> >> Once done, then switch your profile to 17.0 and do the giant emerge -e
> >> world that requires.
> >>
> >> tl;dr
> >>
> >> the news message about perl might make you think the sky will fall on
> >> your head and all your kittens will die, this is actually not true.
> >>
> >> The v5.26 updates mostly had to do with perl's search path for perl
> >> modules. Just like how we've frowned on having "." in the shell PATH for
> >> decades, perl now implemented something like that for modules too. The
> >> possible problem anticipated is that modules would now break if a
> >> modules could not find another module it needs. But this really only
> >> applied to modules outside the perl distribution itself. And the Gentoo
> >> perl team dealt with all that already
> >>
> >> It's widely discussed all over the internet in all the usual places, you
> >> are only affected if one of more of these applies:
> >>
> >> - you write perl modules yourself (solution: update your own code)
> >> - you use many ancient cpan modules that no-one touched for yonks
> >> (solution: maybe use currently supported modules instead)
> >> - you heavily rely on a third party perl app that might not have been
> >> updated - musicbrainz and radiator come to mind as examples (solution:
> >> harass your app vendor)
> >>
> >> -- 
> >> Alan McKinnon
> >> alan.mckin...@gmail.com
> >>
> >>
> > 
> > So, I have already switched to the new profile, should I switch back,
> > do a regular world update, or do the world update with the new profile
> > -- I am compiling gcc as I write, although its not finished yet, I can
> > interrupt it if necessary.
> > 
> 
> 
> 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.
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.




-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

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

[Alan McKinnon]

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
>>> have run into a serious problem with perl.  I think I saw on this list
>>> where perl 5.26 was going to have problems -- maybe until it is
>>> stabilized -- but if I mask it off,  I get the following:
>>
>> Unmask the latest perl and update world with the old profile
>>
>> This will go smoothly as the perl team did an excellent job making sure
>> everything perl-ish in the tree works in concert with everything else.
>> However I do recall that trying to do it with a partial world update
>> didn't work - too many affected packages, so trying just perl + deps did
>> not work. Rather do a normal world update.
>>
>> Once done, then switch your profile to 17.0 and do the giant emerge -e
>> world that requires.
>>
>> tl;dr
>>
>> the news message about perl might make you think the sky will fall on
>> your head and all your kittens will die, this is actually not true.
>>
>> The v5.26 updates mostly had to do with perl's search path for perl
>> modules. Just like how we've frowned on having "." in the shell PATH for
>> decades, perl now implemented something like that for modules too. The
>> possible problem anticipated is that modules would now break if a
>> modules could not find another module it needs. But this really only
>> applied to modules outside the perl distribution itself. And the Gentoo
>> perl team dealt with all that already
>>
>> It's widely discussed all over the internet in all the usual places, you
>> are only affected if one of more of these applies:
>>
>> - you write perl modules yourself (solution: update your own code)
>> - you use many ancient cpan modules that no-one touched for yonks
>> (solution: maybe use currently supported modules instead)
>> - you heavily rely on a third party perl app that might not have been
>> updated - musicbrainz and radiator come to mind as examples (solution:
>> harass your app vendor)
>>
>> -- 
>> Alan McKinnon
>> alan.mckin...@gmail.com
>>
>>
> 
> So, I have already switched to the new profile, should I switch back,
> do a regular world update, or do the world update with the new profile
> -- I am compiling gcc as I write, although its not finished yet, I can
> interrupt it if necessary.
> 


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.


-- 
Alan McKinnon
alan.mckin...@gmail.com

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

[Michael Orlitzky]

On 12/07/2017 09:04 AM, John Covici wrote:
> 
> I have it set to 120 by default.
> 

Um... try "emerge -uDN1 perl" instead of @world? The perl
upgrade was tough, IIRC because it needed a large backtrack value to
succeed. But back when the perl upgrade was "new", a @world update was
simple enough to succeed. Now you've got all the python and profile
stuff going on too, so it might be necessary to upgrade one subsystem at
a time.

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

[John Covici]

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
> > have run into a serious problem with perl.  I think I saw on this list
> > where perl 5.26 was going to have problems -- maybe until it is
> > stabilized -- but if I mask it off,  I get the following:
> 
> Unmask the latest perl and update world with the old profile
> 
> This will go smoothly as the perl team did an excellent job making sure
> everything perl-ish in the tree works in concert with everything else.
> However I do recall that trying to do it with a partial world update
> didn't work - too many affected packages, so trying just perl + deps did
> not work. Rather do a normal world update.
> 
> Once done, then switch your profile to 17.0 and do the giant emerge -e
> world that requires.
> 
> tl;dr
> 
> the news message about perl might make you think the sky will fall on
> your head and all your kittens will die, this is actually not true.
> 
> The v5.26 updates mostly had to do with perl's search path for perl
> modules. Just like how we've frowned on having "." in the shell PATH for
> decades, perl now implemented something like that for modules too. The
> possible problem anticipated is that modules would now break if a
> modules could not find another module it needs. But this really only
> applied to modules outside the perl distribution itself. And the Gentoo
> perl team dealt with all that already
> 
> It's widely discussed all over the internet in all the usual places, you
> are only affected if one of more of these applies:
> 
> - you write perl modules yourself (solution: update your own code)
> - you use many ancient cpan modules that no-one touched for yonks
> (solution: maybe use currently supported modules instead)
> - you heavily rely on a third party perl app that might not have been
> updated - musicbrainz and radiator come to mind as examples (solution:
> harass your app vendor)
> 
> -- 
> Alan McKinnon
> alan.mckin...@gmail.com
> 
> 

So, I have already switched to the new profile, should I switch back,
do a regular world update, or do the world update with the new profile
-- I am compiling gcc as I write, although its not finished yet, I can
interrupt it if necessary.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

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

[Alan McKinnon]

On 07/12/2017 07:44, John Covici wrote:
> Hi. In preparing for the profile switch and the emerge -e world, I
> have run into a serious problem with perl.  I think I saw on this list
> where perl 5.26 was going to have problems -- maybe until it is
> stabilized -- but if I mask it off,  I get the following:

Unmask the latest perl and update world with the old profile

This will go smoothly as the perl team did an excellent job making sure
everything perl-ish in the tree works in concert with everything else.
However I do recall that trying to do it with a partial world update
didn't work - too many affected packages, so trying just perl + deps did
not work. Rather do a normal world update.

Once done, then switch your profile to 17.0 and do the giant emerge -e
world that requires.

tl;dr

the news message about perl might make you think the sky will fall on
your head and all your kittens will die, this is actually not true.

The v5.26 updates mostly had to do with perl's search path for perl
modules. Just like how we've frowned on having "." in the shell PATH for
decades, perl now implemented something like that for modules too. The
possible problem anticipated is that modules would now break if a
modules could not find another module it needs. But this really only
applied to modules outside the perl distribution itself. And the Gentoo
perl team dealt with all that already

It's widely discussed all over the internet in all the usual places, you
are only affected if one of more of these applies:

- you write perl modules yourself (solution: update your own code)
- you use many ancient cpan modules that no-one touched for yonks
(solution: maybe use currently supported modules instead)
- you heavily rely on a third party perl app that might not have been
updated - musicbrainz and radiator come to mind as examples (solution:
harass your app vendor)

-- 
Alan McKinnon
alan.mckin...@gmail.com

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

[John Covici]

On Thu, 07 Dec 2017 07:42:45 -0500,
Michael Orlitzky wrote:
> 
> On 12/07/2017 12:44 AM, John Covici wrote:
> > Hi. In preparing for the profile switch and the emerge -e world, I
> > have run into a serious problem with perl.  I think I saw on this list
> > where perl 5.26 was going to have problems -- maybe until it is
> > stabilized -- but if I mask it off,  I get the following:
> > 
> 
> Try adding "--backtrack=100" to your "emerge" command.
> 

I have it set to 120 by default.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

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

[Michael Orlitzky]

On 12/07/2017 12:44 AM, John Covici wrote:
> Hi. In preparing for the profile switch and the emerge -e world, I
> have run into a serious problem with perl.  I think I saw on this list
> where perl 5.26 was going to have problems -- maybe until it is
> stabilized -- but if I mask it off,  I get the following:
> 

Try adding "--backtrack=100" to your "emerge" command.