Description of problem: There is more than one version of some packages installed. This causes problems with yum performing an update, as dependencies are "broken" when it doesn't work for the existing (older) package. Version-Release number of selected component (if applicable): # yum --version 3.2.12 How reproducible: Quite frequent on this Fedora 9 pre-release. This occurs with some packages and is only noticeable when yum can't "just perform an update". Individual packages need to be selected, and even then I'm left with 50-60 packages that can't be updated. Steps to Reproduce: 1. Uncertain. It's just something that has happened from the installation of the alpha x64 release, and yum doing updates since a month ago. I've not been able to perform a complete update since then. 2. 3. Actual results: More than once version of a package is installed, preventing an update. Expected results: When an update is performed, for the old version to be removed so it's no longer a problem. Additional info: Sample versioning problem attached. Can attach more yum-related output if it's helpful.
Created attachment 298623 [details] Sample yum output showing more than one version of a package installed.
Created attachment 298624 [details] Another package with more than one version installed. I found another package with more than one version installed, preventing it from being updated.
In most of these cases there was some sort of unpacking or scriptlet error during the transaction which failed to let the package complete the 'cleanup' portion of the update. That happens more than is good in rawhide. b/c the other package is installed you can fix this by running: rpm -e pkgname-ver-rel.arch that you wish to remove. But there's not much here to fix in yum.
I have 42 cases of it in Rawhide at the moment that I've still to fix. Are you suggesting that it's a problem with each of those packages instead of yum / rpm?
yes.
Are you also suggesting that I file bugs under the respective packages, instead of yum?
It doesn't even have to be bugs in the individual packages - all it takes is a slight selinux-mixup to have all scriptlets failing, leading to a mass dupe-attack such as this. Impossible to say anything without seeing the original transaction log which left the dupes around. I'm going to make rpm ignore error exits on scriptlets other than %pre in upstream but that wont help here...
Even with SE-Linux set to permissive? Or are you just indicating that it's a fragile system, and that it could be ANYthing...?