On 3/8/19 2:29 PM, Panu Matilainen wrote:
On 3/8/19 1:54 PM, Florian Weimer wrote:* Panu Matilainen:On 3/7/19 5:52 PM, Florian Weimer wrote:* Panu Matilainen:On 3/7/19 1:13 PM, Florian Weimer wrote:* Richard W. M. Jones:$ sudo dnf install glibc-headers.i686…Downgrading:That looks like a bug in itself.The last time I looked at something similar, I saw this: RPM would notadjust a pre-existing symbolic link to a new target very late in the transaction. Like deleting old files which are gone in an update ordowngrade, this does *not* happen when the unpacking of the replacement package happens, but towards the conclusion of the transaction. In themeantime, scriptlets run with the broken file system.In your case, maybe one of the scriptlet errors prevented the final stepwith the adjustment of the symbolic link by RPM. (Just to be clear, the symbolic link is regularly packaged, it's not something that we manage using scripts.)IIRC the issue is that at when ldconfig runs from the package scripts, on downgrade the newer file is still on disk and thus ldconfig leaves the link the way it is, but at the end of transaction it'll be gone and symlinks can be broken.Is there a chance that RPM will be changed to run more scriptlets with the final disk contents?There's %transfiletriggerin, %transfiletriggerpostun and %posttrans that run after the entire transaction, and then the individual postun-type scripts/triggers. What is it that you're missing?Correct symbolic links. If the symbolic links are not installed as they are in the packaged contents before running scriptlets (any scriptlets), we need to bring back the ldconfig scriptlets. This is not just a problem for glibc.Ehm? Symlinks are installed just like any other content, and rpm has no reason to mess with them. Like I said above, the problem is almost certainly a mistimed ldconfig causing the links changed back to the version that is about to get removed.
Hmm, except that in this particular there shouldn't be any mistimed ldconfigs present. Perhaps I should take a closer look.
Note that the scenario with ldconfig is very real though, as long as *any* package runs ldconfig in middle of a transaction involving downgrades, the links can get misadjusted to version(s) that will be removed, and unless ldconfig is run again after that removal, things will be broken. Back when each and every library package ran ldconfig in its post and postun, things also got fixed right away. Now that some do and others dont, its more of a mixed bag. Either ldconfig should only run once at the very end, or it should run after each library package.
- Panu -
- Panu -
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
