On 10/12/2017 14:54, John Covici wrote: > On Sun, 10 Dec 2017 07:36:19 -0500, > Kent Fredric wrote: >> >> [1 <text/plain; US-ASCII (quoted-printable)>] >> On Sun, 10 Dec 2017 02:17:09 -0500 >> John Covici <cov...@ccs.covici.com> 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
