On 3/11/19 12:29 PM, Florian Weimer wrote:
* 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.
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.
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.
- Panu -
_______________________________________________
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
