id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
260	Failures when updating critical components in a batch	dmik		"There are known failures if a number of critical components related to YUM/RPM are being updated in a batch (e.g. by `yum update` which tries to install all available updates).

Consider this scenario: some DLL to be updated (e.g. LIBCx) gets a new function that is used by some application to be updated which is part of the update tool itself (e.g. RPM) and there also are some other applications to be updated in this batch besides the first two.

First, YUM will update LIBCx (all fine). Then it will update RPM using the older RPM which uses the old LIBCx (also fine as the old LIBCx is kept in memory by python running YUM even after being replaced by a new LIBCx). From this point on YUM will try to use the new (updated) RPM executable to install the remaining updates in the batch. But given that the new RPM needs the new LIBCx which won't be loaded because the old one is still in memory, it will have to use the old one but the old one misses a function it needs, so RPM will bail out. There are other possible scenarios similar to this one.

The only workaround for this problem is to update packages in a specific order which is manually defined by the user. I.e. in the above scenario it would be `yum update libcx` followed by a reboot (to have a newer LIBCx loaded), then update all the rest (other failing scenarios could require a different order). This clearly needs a better solution as forcing the end user to decide which packages to update first and do it manually beats the whole purpose of the smart package manager.

This ticket originates from #257 which contains a real life example in the comments."	defect	new	critical		rpm		medium