| 1 |
On 10/12/2017 14:54, John Covici wrote: |
| 2 |
> On Sun, 10 Dec 2017 07:36:19 -0500, |
| 3 |
> Kent Fredric wrote: |
| 4 |
>> |
| 5 |
>> [1 <text/plain; US-ASCII (quoted-printable)>] |
| 6 |
>> On Sun, 10 Dec 2017 02:17:09 -0500 |
| 7 |
>> John Covici <covici@××××××××××.com> wrote: |
| 8 |
>> |
| 9 |
>>> OK, thanks, I think I will try that. |
| 10 |
>> |
| 11 |
>> The problem you're facing is that you masked dev-lang/perl, but not any |
| 12 |
>> virtual/perl-* or perl-core/-* to compensate. |
| 13 |
>> |
| 14 |
>> These 3 components work in concert like a single component, as a sort |
| 15 |
>> of bodge to compensate for the fact portage has no working "provides" feature, |
| 16 |
>> and to compensate for the dependency-system missmatch between how |
| 17 |
>> Gentoo works and how CPAN works. |
| 18 |
>> |
| 19 |
>> Theres' no easy way of fixing this atm, but the short of it is if you're using |
| 20 |
>> an ~arch dev-lang/perl, you should be using an ~arch virtual/perl-*, |
| 21 |
>> and if you're using an "arch" dev-lang/perl, you should be using only |
| 22 |
>> "arch" versions of virtual/perl-* |
| 23 |
>> |
| 24 |
>> Once you do this, portage may still scream at you, because portage is |
| 25 |
>> very much optimised for upgrading, and it tends to think downgrading is |
| 26 |
>> an error. |
| 27 |
>> |
| 28 |
>> So once you get all your masks/keyword changes in place, you should do: |
| 29 |
>> |
| 30 |
>> emerge -C virtual/perl-* |
| 31 |
>> emerge -C perl-core/* |
| 32 |
>> |
| 33 |
>> (or something to that effect) |
| 34 |
>> |
| 35 |
>> This looks scary, but generally isn't, because you're not actually removing |
| 36 |
>> anything with this, just juggling a few balls and making only older |
| 37 |
>> versions of certain things available ( as they're alls shipped in |
| 38 |
>> dev-lang/perl ) |
| 39 |
>> |
| 40 |
>> And then after you do this, portage is more likely to be persuadable |
| 41 |
>> into doing the right thing. |
| 42 |
>> |
| 43 |
>> You can additionally abuse my tool, gentoo-perl-helpers for doing some of this, |
| 44 |
>> and some of the steps I've described are automated because they're just |
| 45 |
>> that safe and useful. |
| 46 |
>> |
| 47 |
>> https://wiki.gentoo.org/wiki/Perl#app-admin.2Fgentoo-perl-helpers |
| 48 |
>> |
| 49 |
>> |
| 50 |
>> After putting the right masks in place, do: |
| 51 |
>> |
| 52 |
>> gentoo-perl gen-upgrade-sets 5.26 5.24 |
| 53 |
>> |
| 54 |
>> And if you're really lucky, the sets it generates will work the first time :) |
| 55 |
>> |
| 56 |
>> ( I actually tested this scenario when developing it, but its still an |
| 57 |
>> undocumented use on purpose ) |
| 58 |
>> |
| 59 |
>> GLHF. |
| 60 |
> |
| 61 |
> I went ahead and did the upgrade which worked, but the emerge from |
| 62 |
> perl-cleaner --all did not. I am using ~amd64 and have done so for |
| 63 |
> years, so I don't think I need to maks off anything. I seem now to be |
| 64 |
> stuck with dev-python/setuptools, so I am now trying to figure out why |
| 65 |
> I can't emerge that -- it was triggered by the perl-cleaner --all . |
| 66 |
> |
| 67 |
|
| 68 |
How recent is your tree? |
| 69 |
|
| 70 |
I had issues with setuptools doing the first run through the 17.0 |
| 71 |
upgrade. I never looked into it too closely, I used --keep-going, but |
| 72 |
setuptools seemed to think I had a useable python-3.4 |
| 73 |
|
| 74 |
After the first run through emerge -e world, nuking-python-3.4 and |
| 75 |
re-syncing, setuptols worked normally again. |
| 76 |
|
| 77 |
YMMV of course where you are |
| 78 |
-- |
| 79 |
Alan McKinnon |
| 80 |
alan.mckinnon@×××××.com |
Archives