* Panu Matilainen: >> 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. > > The answer is basically twofold: > > 1) Rpm cannot do removals as long as there are dependencies on the > older versions, eg on library soname changes an early erasure could > cause scriptlet failures from dependent packages. You mean the %postun fails for a dependency because it runs after the upgrade to the new soname, and the new soname is gone at that point? (This obviously does not apply to glibc anytime soon.) > 2) Hardcoded removals after install has the virtue of simplicity, > both in terms of implementation and being rather idiot-proof: installs > and erasures could be safely interleaved IFF the dependency data from > packages is perfect. For install-scripts it usually is close enough, > but much less so for erasure. Given the potentially dramatic outcome > of early erasure gone wrong, simple-and-stupid doesn't seem so stupid. I don't understand this point. It is possible interleave file system changes arbitrarily until you run scriptlets. But RPM does not do this because it runs non-trigger scriptlets immediately, so it rarely provides a consistent execution environment for scriptlets. 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
