Prologue - I know, I use a masked portage version, but recent updates to QT / KDE would have been a mess without. Under the following situation portage commits suicide : - option --usepkg - there is a new glibc - there is a new bash linked to the new glibc Having looked at the dead system (from a SystemRescueCD), the new bash has been installed before the new glibc has been (completely?) installed. The result: no shell did work anymore portage fails even a chroot to the system fails since there is no working shell I could survive by doing an rsync (/lib and /bin) from the target machine. Still, quite unpleasant. Probably glibc and other packages vital to the shell (and maybe python) should be replaced first. Probably the same problem occurs with versions 2.1.x Reproducible: Always
I hopefully updated the Summary to be less spectacularly dramatic and to more exactly and dryly specify what exactly happened...
Adding virtual/libc to the bash dependencies would solve this. Given the virtual/libc dependencies are typically unspecified, I guess we should add a hack in the dependency resolver to automatically promote virtual/glibc to the front of the list, similar to how sys-apps/portage is automatically promoted.
Created attachment 219959 [details, diff] merge libc asap Save as /tmp/libc_asap.patch and apply as follows: cd /usr/lib/portage patch -p0 < /tmp/libc_asap.patch
This is fixed in 2.1.8 and 2.2_rc64.
Actually, the current won't necessarily work with --jobs > 1, so this needs a little more work.
Created attachment 222767 [details, diff] install libc asap while accounting for parallel builds
This is fixed in 2.1.8.3 and 2.2_rc67.
