1 |
I've bitten by this too... the problem is that portage does not follow a particular order when rebuilding subslot deps, so when upgrading dev-libs/libffi (in this case from 0/7 to 0/8) it can schedule lots of other packages between when the new libffi is installed and when python is rebuilt. If portage is interrupted for any reason during this period, you're screwed. |
2 |
|
3 |
To recover, I followed these steps: |
4 |
|
5 |
1. temporarily bring back /usr/lib/libffi.so.7 (/usr/lib64/libffi.so.7 if you're on amd64) from whatever source you can find (backup, saved binpkg, livecd/usb). You will need to copy both the actual library (libffi.so.7.x.y) and the versioned symlink (libffi.so.7 -> libffi.so.7.x.y); make sure you do not touch the existing libffi.so -> libffi.so.8.z.w symlink |
6 |
2. re-emerge your main python version (the one you use to run portage, see emerge --info) |
7 |
3. finish your upgrade |
8 |
4. remove the files you copied in 1 |
9 |
5. do a revdep-rebuild pass, just in case |
10 |
|
11 |
I would not call installing dev-libs/libffi-compat a solution -- you still need a working python to do that, and it won't protect you from future breakage like this. |
12 |
|
13 |
>> This may help: |
14 |
>> |
15 |
>> https://wiki.gentoo.org/wiki/Project:Portage/Fixing_broken_portage |
16 |
|
17 |
It will not help in this case, since what's broken is python and not portage. |
18 |
|
19 |
> If that won't work for whatever reason, chroot into your system after you boot |
20 |
> with the latest Live-USB and try to update @system. Alternatively, reinstall. |
21 |
|
22 |
Neither will this, as you won't be able to execute python (i.e. run portage) inside the chroot. |
23 |
|
24 |
HTH |
25 |
|
26 |
andrea |