popt update fails

[CollieJim]

package-updater tells me that an update for popt is available. When I try to update, I get the following errors:
file /usr/share/locale/cs/LC_MESSAGES/popt.mo from install of popt-1.13-1.fc8.i386 conflicts with file from package popt-1.12-3.fc8.x86_64
file /usr/share/locale/da/LC_MESSAGES/popt.mo from install of popt-1.13-1.fc8.i386 conflicts with file from package popt-1.12-3.fc8.x86_64
<snip>
file /usr/share/locale/wa/LC_MESSAGES/popt.mo from install of popt-1.13-1.fc8.i386 conflicts with file from package popt-1.12-3.fc8.x86_64

"rpm -qa | grep popt -" gives
popt-1.12-3.fc8
popt-devel-1.13-1.fc8
popt-1.13-1.fc8
popt-1.12-3.fc8

"rpm -e --nodeps popt-1.12-3.fc8" fails with
error: "popt-1.12-3.fc8" specifies multiple packages

How do I get rid of 1.12-3.fc8 so I can install the update?
Why are there two packages with the same name?

TIA
Jim

[Akdor 1154]

One's an i386 package, one's an x86_64 package. Yum sucks and won't let one overwrite the files of the other even though they're shared between both packages. To remove the i386 package: yum remove popt.i386 should work nicely. The problem with this is if you have an i386 package that depends on popt, for instance, Wine. In that case, wait for someone with more experience than I to come along and give advice.

[Hlingler]

Hello:

It is certainly baffling why you have multiple popt packages installed, two with the same revision and release number.

Try: rpm -ev --nodeps popt*
If that works, there will be no updates (because the packages will be gone), so: yum install popt.

V

[Akdor 1154]

Originally Posted by Hlingler

Hello:

It is certainly baffling why you have multiple popt packages installed, two with the same revision and release number.

Try: rpm -ev --nodeps popt*
If that works, there will be no updates (because the packages will be gone), so: yum install popt.

V

Not cool, at all, as yum doesn't work without popt installed as I just found out. :o

[Hlingler]

Sorry, an oops indeed - my bad if that's the case. All I can say is: I answered the question without researching the impact.

Hopefully, popt can be re-installed with rpm, but you'd have to manually fetch the popt RPM or tell rpm where to go to get it. rpm.pbone.net search will give URLs.

V

[Akdor 1154]

According to

rpm: error while loading shared libraries: libpopt.so.0: cannot open shared object file: No such file or directory

,
popt cannot be easily installed by RPM either. Hmm this will be fun to fix, fantastic.

Umm options: install from source. Quite possible. Option 2: manually extract RPM and put libpopt where rpm can find it, then install from repo. Either way is hacky but I'm leaning towards 2 as it's possible that Fedora has put their own changes in popt. So, what can I use to open RPMs that's already on my computer and doesn't rely on popt?

[Hlingler]

rpm depends on popt also. Recovery from my gaff may be possible with smart package manager: http://labix.org/smart. Installation of smart does not require yum or rpm, IIRC (might want to verify that on your own...). It comes with a python installer. Instructions included. I'll stay with you, since this is my fault.

V

[Hlingler]

BTW, you can indeed open an RPM with file-roller or one of the other archivers, and extract individual files....

V

[Akdor 1154]

Fixed now, thanks for the help.

Steps to fix for someone else in this unfortunate situation:
I couldn't use file-roller as I'm on KDE, and as everybody knows, Ark is pretty much piss-weak. So after a quick Google on the RPM file format, I tried the following with great success:

Download Fedora's x86_64 popt rpm from the ftp redhat download site.
Load it into KEdit, find the first occurence of the two bytes "1f 8b", delete everything BEFORE these two bytes, save as a new file.gz.
The new file is a gzipped CPIO archive, so unzip the single file it contains with anything. In my case this was one of the few things Ark was capable of.
Open a terminal: cpio --extract --no-absolute-filenames -I [unzipped file]
You should now have a usr, etc, and lib64 directory (unlikely that an x86 user would be in this mess). su and cp libpopt.so.0.0.0 into /lib64, then ln -s /lib64/libpopt.so.0.0.0 to /lib64/libpopt.so.0.

Now yum should work, so you can install things properly with a simple yum install popt.

[Hlingler]

Glad you got it fixed, and fairly quickly and easily. Sorry again about the problem - obviously, forcibly removing anything with "rpm -e --nodeps..." is potentially a very dangerous thing. We learn.

Regards,
V

[Hlingler]

I gave the OP's question a lot more thought. One of the apparently duplicate popt-1.12-3.fc8 packages must be x86 and the other x86_64. The safe query to reveal this is:

rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n"|grep popt

The results will look thus:

popt-1.10.2.2-2.fc7.i386

Then, knowing this, the extraneous packages can be surgically removed by explicit name, (instead of a wildcard glob and/or force), for example with: rpm -ev popt-1.12-3.fc8.i386 popt-1.12-3.fc8.x86_64 (i.e., no need to use --nodeps). You would also have to decide whether to remove the two packages marked revision 1.12-3, or two of the packages marked i386 or x86_64. At least one of the three packages must remain. There is, of course, still a danger that, even if the transaction succeeds, common files belonging also to the remaining package may also get dragged out, crippling yum and rpm. Or the transaction may simply fail if common files exist - I'm not sure. Yum may be a better tool to try that with, since it will at least ask for confirmation before commiting on the transaction (don't pass the "-y" option): yum remove popt-1.12-3.fc8.i386 popt-1.12-3.fc8.x86_64. That still appears to leave a question as to whether the existing popt-1.13-1.fc8 is an i386 or x86_64 flavor, an therefore why your original command seemed to want to update it with yet another duplicate package, but you'll find that out with the above query.

The above assumes that the duplicate packages are for different architectures. And this time, I'm going to state right now that this could be a very dangerous transaction to pull off unless you are really comfortable with what's going on. If you're not sure, ask more questions and wait until someone more knowledgeable and experienced can give you clearer/more certain guidance (didn't someone already say that...).

Regards,
V

[CollieJim]

Thanks for the replies. I found that smart gives sufficient granularity that I was able to explicitly say to delete the 1.12 and install the 1.13 versions, rather than updating.

It did cause a bit of worry though when rpm wanted to delete itself along with 1.12.