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
not
adjust a pre-existing symbolic link to a new target very late in the
transaction. Like deleting old files which are gone in an update or
downgrade, this does *not* happen when the unpacking of the
replacement
package happens, but towards the conclusion of the transaction.
In the
meantime, scriptlets run with the broken file system.
In your case, maybe one of the scriptlet errors prevented the
final step
with 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 -- 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
