Well, I am not figuring out how to revive my system once I downgraded by accident from 1.2.6 to latest stable and gcc died with: cc: /lib64/libz.so.1: version `ZLIB_1.2.5.2' not found (required by cc) If I don't misremember, glibc already has a way to die when people try to downgrade it, could the same be done with zlib? Thanks a lot Reproducible: Always
there are a lot of libraries that can do this. i don't think special casing zlib makes sense when none of them do.
Maybe we should have a standard way to tell package managers to not downgrade when it can break systems completely, not sure if this has been discussed before :/
(In reply to comment #2) > Maybe we should have a standard way to tell package managers to not > downgrade when it can break systems completely, not sure if this has been > discussed before :/ We can also finally get portage with preserved-libs which would probably avoid such a breakage.
That would be interesting, but looking to bug 240323 I don't think we are close to get it supported in stable portage :(
(In reply to comment #3) i don't think (current) preserved-libs would make a difference. the issue isn't a changed SONAME, it's trying to go back to an older version of that SONAME. portage makes sure we keep libz.so.1, not libz.so.1.2.5 vs libz.so.1.2.3.3. although if it were extended, it could handle this.
Maybe trying to extend it to do so could also help in cases like people downgrading pcre and finding broken grep just after downgrade, but I have no idea if it could be handled without adding more issues (will CC dev-portage team)... and still is the problem of preserve-libs still having some issues hard to solve that will delay its inclusion in stable tree for some time I think...
(In reply to comment #5) > i don't think (current) preserved-libs would make a difference. the issue > isn't a changed SONAME, it's trying to go back to an older version of that > SONAME. portage makes sure we keep libz.so.1, not libz.so.1.2.5 vs > libz.so.1.2.3.3. although if it were extended, it could handle this. If the SONAME symlink (libz.so.1 -> libz.so.1.2.5) is pointing at the older version (it does this when you downgrade, since bug 373341), will the linker know that we want it to search for a different provider such as libz.so.1.2.7 when needed? We don't have the metadata for that in /var/db/pkg/*/*/NEEDED.ELF.2, since it only references the libz.so.1 SONAME.
FYI: libiconv/gettext are even more fatal with USE=nls on non-glibc platforms (even e.g. bash and ls no longer run)
(In reply to comment #7) if you have libz.so.1.2.3 and libz.so.1.2.5 (and both have same SONAME), ldconfig knows to link libz.so.1 -> libz.so.1.2.5 (since .5 is newer than .3) (In reply to comment #8) bash requires readline/ncurses on Linux systems today (it didn't use to, but i changed that)
(In reply to comment #9) > (In reply to comment #7) > > if you have libz.so.1.2.3 and libz.so.1.2.5 (and both have same SONAME), > ldconfig knows to link libz.so.1 -> libz.so.1.2.5 (since .5 is newer than .3) Right, but since portage calls ldconfig -X (in order to facilitate downgrades as discussed in bug #373341), the default portage behavior is to preserve the symlink from the most recently installed version. That means that somebody has to call ldconfig without -X if they want to replace those symlinks.
