Red Hat Bugzilla – Bug 438283
more than one version of packages installed
Last modified: 2014-01-21 18:02:06 EST
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
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
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.
More than once version of a package is installed, preventing an update.
When an update is performed, for the old version to be removed so it's no longer
Sample versioning problem attached. Can attach more yum-related output if it's
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?
Are you also suggesting that I file bugs under the respective packages, instead
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...?