On Sun, 21 Jan 2007 22:04:27 -0600, wayne wrote: > If libSDL_gfx.so.13 was on my computer and was not recognized as such, > what would cause that? An upgrade to an incompatible SDL_gfx package provided in a non-Fedora repository. Or a hopelessly broken RPM database. Yum *does* see the installed libSDL_gfx.so.13 just like rpm -qf /usr/lib/libSDL_gfx* does, e.g. yum list SDL_gfx *But* if there is a package upgrade to the libSDL_gfx.so.0.0.15 you've talked of, the old files are not available anymore and are not in the transaction check either. They would be gone with the upgrade, which fails because other files still need the older SDL_gfx package. So, look into what SDL_gfx package version is installed and what package would be installed by "yum upgrade". Find out where it comes from. > That was the symbolic link available but yum > didn't recognize the it as such as that package did not meet the > dependency requirements and the whole process failed. With all due respect, this is nonsense. "rpm -ql SDL_gfx" lists the files *any* symlinks included in the package, and the symlink is included, too. > Which repos could cause that? I believe the only one I have that is not > Fedora is for NVidia drivers, and I only enable it when the kernel is > updated so that I can use my NVidia graphics card. Instead of guessing that you could simply verify which repositories you have enabled. You've talked about a version of SDL_gfx that is not provided in Fedora Extras 6 and "Development" packages yet. Where does it come from? > I kept getting error messages during yum -y update attempts. After "yum > remove frozen-bubble" and "yum remove perl-SDL" attempting to run "yum > -y update" generated a lockup of the terminal session with many lines of > ascii characters. Also messages about a corrupt database. "rpm --vv > --rebuilddb" did not work. After "cd /var/lib/rpm" then "rm -f *.00*" I > was able to successfully use "rpm -vv --rebuilddb" and then run "yum -y > update". Well, can you accept that all this is abnormal behaviour? You cover multiple problems in one mail. Problems with an incompatible SDL_gfx package from an unknown location and corruption with RPM. That doesn't make it easy if the investigation work is not done by you. > Also, after I received this response from you, I received the below from > the website from the above link: That is irrelevant. You search in wrong places. SDL_gfx in Fedora Extras is still at v2.0.13. Only if you mess with upstream package releases or non-Fedora packages, you run into the problems with the SONAME change. > Until then please try the following: > - you can try to locate the new SDL_gfx rpm, download it manually and > force an installation using "rpm -Uvh --force --nodeps *.rpm" And this is a big fat DO NOT. Whoever has recommended those rpm options has given you very bad advice. It's not just that --force is permitted to overwrite arbitrary files from other packages, --nodeps ignores package dependencies altogether and only increases problems with further installs. -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list