Last night I was updating my FC6t1 system that is an x86_64 box. I installed this from the DVD iso and have always gotten updates since then by running pup.
I got conflicts last night that were complaining about some library being needed by gnopernicus, so I did an rpm -q gnopernicus and found I had two gnopernicus rpms installed, both the same version, one i386 and one x86_64. Usiing the --list option, I found both of them install many files with the exact same name (no /lib versus /lib64), so it is hard to see how both rpms could actually be correctly installed simultaneously.
Has pup screwed up at some point and installed i386 rpms when it should have picked x86_64 ones? Have the repos gotten corrupted at some point? Or is it really legitimate to have two conflicting rpms like this?
tomhorsley@adelphia.net wrote:
Last night I was updating my FC6t1 system that is an x86_64 box. I installed this from the DVD iso and have always gotten updates since then by running pup.
I got conflicts last night that were complaining about some library being needed by gnopernicus, so I did an rpm -q gnopernicus and found I had two gnopernicus rpms installed,
Can you post the exact error?
both the same version, one i386 and one
x86_64. Usiing the --list option, I found both of them install many files with the exact same name (no /lib versus /lib64), so it is hard to see how both rpms could actually be correctly installed simultaneously.
Has pup screwed up at some point and installed i386 rpms when it should have picked x86_64 ones? Have the repos gotten corrupted at some point? Or is it really legitimate to have two conflicting rpms like this?
Yes. RPM multi arch support works that way.
Rahul
On Fri, 2006-07-14 at 18:31 +0530, Rahul wrote:
tomhorsley@adelphia.net wrote:
I got conflicts last night that were complaining about some library being needed by gnopernicus, so I did an rpm -q gnopernicus and found I had two gnopernicus rpms installed,
Can you post the exact error?
It was just the same old error I always get on at least one thing every update because a new library has shown up in the updates but something installed needs the old library to still exist. The specific gnopernicus error seems to be gone today, but here are a couple of new ones just like it :-)
Missing Dependency: libgsf-gnome-1.so.114()(64bit) is needed by package gnucash Missing Dependency: libdw.so.1(ELFUTILS_0.120)(64bit) is needed by package systemtap
Or is it really legitimate to have two conflicting rpms like this?
Yes. RPM multi arch support works that way.
I guess I really really don't understand multi arch rpms then. For instance, the --list info for both the gnopernicus rpms claims they own the files:
/usr/bin/gnopernicus /usr/bin/gnopernicus-mag-config /usr/bin/srcore
yet the installed files are in fact ELF 64-bit executables, which seem unlikely to be packaed in an i386 rpm :-). Is there some doc somewhere that clarifies this multi arch stuff so I can perhaps reduce my confusion?
On Friday 14 July 2006 08:57, tomhorsley@adelphia.net wrote:
Has pup screwed up at some point and installed i386 rpms when it should have picked x86_64 ones? Have the repos gotten corrupted at some point? Or is it really legitimate to have two conflicting rpms like this?
Yum, which pup users, will install both the i386 and the x86_64 version of a package if you request to install "package". This ensures that you have a proper environment for running 32 bit software if need be.
If there is a conflict between the i386 and the x86_64 version of a package provided in the x86_64 repository, then there is a bug in said package. If the package is supplied multiarch it must not have any conflicts.