* Panu Matilainen: > It's glibc's own %post own scripts that are somehow breaking it. I've > a minimal reproducer here with glibc 2.29 in /srv/root chroot. The > bash version is just to show whether bash is alive or not: Yes, you are right, I had actually looked at this failure a few weeks ago and reached similar conclusions (my memory is failing). > glibc's %post is /usr/sbin/glibc_post_upgrade.<arch>, so that's what's > doing something bad here. When straced through forks and all, guess > what? It's running ldconfig: Right, we have to do that unfortunately. So the problem is not the symbolic link handling, but the fact that the scriptlets run while old files still stick around, before RPM deletes them closer to the end of the transaction. And *this* happens because we use symbolic links to the actual implementation. If we didn't do that, RPM would have no choice and would have to replace the files on disk, so that the old version is gone. We actually have compensating code in glibc_post_upgrade for these lingering files, deleting files early that would break scriptlets which run before they are deleted by RPM. The question is whether we want to extend this code to cover more cases. This is quite hard to do however, especially for downgrades, because we do not know which files to delete in the %post scriptlet of the old version (which cannot foretell the changes the newer glibc version that is being removed brought in). Presumably, we could look at the file list in the RPM database and delete anything that's not part of the current package version (the one whose %post is running). I had already raised the issue with the symbolic links upstream (as I said, my memory is failing), and feedback was not exactly positive: <https://sourceware.org/ml/libc-alpha/2018-11/msg00612.html> In fact, Siddhesh suggested using *more* symbolic links: <https://sourceware.org/ml/libc-alpha/2018-12/msg00348.html> What's RPM's justification for deleting files so late in the transaction? Can this be changed at the RPM level? I'm sure we aren't the only ones affected by this. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
