When upgrade from older sys-libs/glibc versions when it's being used "emerge --usepkgonly world" May show this error: >>> Emerging binary (11 of 534) app-arch/zstd-1.4.9::gentoo * zstd-1.4.9.tbz2 MD5 SHA1 size ;-) ... [ ok ] >>> Extracting info >>> Extracting app-arch/zstd-1.4.9 zstd: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by /lib64/liblzma.so.5) tar: This does not look like a tar archive tar: Exiting with failure status due to previous errors command 'zstd -d --long=31' failed with status 1 Reproducible: Always
This bug report really does not contain sufficient information. What version of glibc was app-arch/xz-utils built against? (a) What version of glibc was installed when you encountered this error? (b) If version a is greater than version b, how exactly did you end up in that situation? These are questions that should be figured out in a support channel. If you identify an actual bug, feel free to re-open this.
My best guess is that you have <sys-libs/glibc-2.32 installed, and you are installing a binpkg of app-arch/xz-utils built against >=sys-libs/glibc-2.32. There seems to be some special handling in Portage to force glibc to be upgraded first, but perhaps you stumbled upon an edge-case.
It looks like it's due to PORTAGE_PACKAGE_ATOM pulling in zstd, which makes it fallout from bug 715108. The merge order calculation uses these constants: lib/portage/const.py-PORTAGE_PACKAGE_ATOM = "sys-apps/portage" lib/portage/const.py:LIBC_PACKAGE_ATOM = "virtual/libc" lib/portage/const.py-OS_HEADERS_PACKAGE_ATOM = "virtual/os-headers"
I have started to update a server a little outdated, The server had installed sys-libs/glibc-2.29-r7 and app-arch/xz-utils was compiled with sys-libs/glibc-2.32-r7
Created attachment 699912 [details] emerge.log This is emerge log
(In reply to Mike Gilbert from comment #2) > My best guess is that you have <sys-libs/glibc-2.32 installed, and you are > installing a binpkg of app-arch/xz-utils built against >=sys-libs/glibc-2.32. > > There seems to be some special handling in Portage to force glibc to be > upgraded first, but perhaps you stumbled upon an edge-case. Yeah, this seems to be what just happened to me too.
(In reply to INODE64 Sistemas from comment #4) > I have started to update a server a little outdated, The server had > installed sys-libs/glibc-2.29-r7 and app-arch/xz-utils was compiled with > sys-libs/glibc-2.32-r7 Ack. Not sure how it is handled in portage, but that needs improvement.
A 90% solution has been implemented in bug 913628 which should prevent this happening. I'll close this accordingly, given bug 753500 tracks the more general solution to this.
