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@xxxxxx
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.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list