yum leaving multiple versions installed

Jim Cornette fct-cornette at insight.rr.com
Sat Feb 4 21:12:27 UTC 2006


Thomas J. Baker wrote:
>
>>
>> I've been using this to list the duplicates:
>>
>>  rpm -aq --queryformat "%{NAME}\n" | sort | uniq -c | grep -v -E " *1 "

This script works great! I added this to my tool arsenal. There were 
many instances where this would be needed information. Thanks!

~/find-dupes.sh
       2 gpg-pubkey
       2 kernel
       2 kernel-devel



>>
>> and something like this:
>>
>>  for i in $(rpm -aq --queryformat "%{NAME}\n" | sort |
>>             uniq -c | grep -v -E " *1 " | gawk '{print $2}'); do
>>    rpm -e --nodeps $(rpm -q $i |head --lines=-1)
>>  done

What will happen for the kernel and gpg-pubkey?

>>
>> to remove them. I'm not sure if that's any better than yours.
>>
>> I guess "rpm -V $package" is a good idea after "rpm -e <old>" and I've even
>> done "rpm -i --force <new>" to be sure (after removing duplicate glibc's
>> etc). -V hasn't usually reported problems, though.

What about Upgrading using --replacefiles --replacepkgs instead of using 
install and --force? This worked for me when trying to make programs verify.

>>
>> And yes, this is often needed. Just yesterday, yum update from rawhide
>> decided to update around 200 package. It churned the harddisk led for ages
>> and then went on updating. It didn't take particularry much memory or
>> anything, and everything seemed normal. But after installing ~30 packages,
>> it just quit quietly. No errors or anything. Yum didn't run the cleanup
>> stage at all, so I had 30 duplicate packages installed. 

%post errors are also a problem. This check to verify the integrity of 
the package installations would probably make a good item to add for 
system reports. Running the check-duplicates is fast and easy enough though.

>>
>> Trying to rerun yum update caused its memory usage to skyrocket and it
>> brought the whole system to its knees. Mouse moved every minute or so, and
>> eventually kernel OOM rambo killed yum (after slaughtering 10 or so innocent
>> processes, bleah) which restored the box back to life. I had to manually rpm
>> -F the packages from /var/cache/yum/development/packages and then weed out
>> the 30 duplicates.

Killing processes to make room for runaway processes seems to bad logic 
in my view.

>>
>> The "yum quits silently in install stage" problem has happened at least three
>> times for me, usually when the rawhide update has been large due to few
>> days' delay in updating.

If this happens frequently and seems to only relate to multiple entries 
in the rpmdb, did you consider %post errors during package installation 
might be a problem?
I have not seen too many yum exiting unexpectedly but have had %post 
scriptlet errors allowing yum to finish its process and exit.


>>
>> Couldn't yum clean up more often (even after installing each package)? It
>> would be nice if yum could somehow slice the large updates to something it
>> can swallow without breaking, but I guess that's more complicated.

That is a lot excessive writing to the rpmdb file and a lot more chances 
for things to go wrong. I would favor a modification to your duplicates 
script for yum or a plugin to check for no duplicate packages other than 
kernel gpg-pubkeys with a way to add other packages that could have 
multiple versions installed to its ending process. I guess for i686 and 
64-bit systems, expanded architecture information would give packages 
differentiation to not be considered duplicates but co-arch versions.

>>
>>
>> -- v -- 
>>
>> v at iki.fi
>>
> 
> I use justdb because in all my cases, it seems the new rpm is really
> installed but the old one is not erased from the database. After
> erasing, my script then verifies the newer rpm to make sure it is really
> installed so it is a good idea to keep an eye on the results.

I've seen the same. I assume that the older files are replaced by the 
newer version of the program. Is there a way to run a check for anything 
that is in /usr/bin which is not owned by any installed program? (other 
program directory locations also would be handy)


> 
> tjb

Jim
-- 
The person who can smile when something goes wrong has thought of
someone to blame it on.




More information about the fedora-test-list mailing list