> with rpm you can do:
>
> rpm -e name.arch
>
> with yum you can do the same:
>
> yum remove name.arch
An even better way to remove them all at once.
rpm -qa --queryformat="%{name}-%{version}-%{release}.%{arch}\n" | grep
devel | grep i386 | xargs rpm -e
Yet another problem: On a system with dual x86_64 and i386 libraries
many
rpms are installed by default for both architectures, an example is
mozilla, the default install of FC3 contains these:
mozilla-1.7.3-17.x86_64.rpm
mozilla-chat-1.7.3-17.x86_64.rpm
mozilla-devel-1.7.3-17.x86_64.rpm
mozilla-dom-inspector-1.7.3-17.x86_64.rpm
mozilla-js-debugger-1.7.3-17.x86_64.rpm
mozilla-mail-1.7.3-17.x86_64.rpm
mozilla-nspr-1.7.3-17.i386.rpm
mozilla-nspr-1.7.3-17.x86_64.rpm
mozilla-nspr-devel-1.7.3-17.x86_64.rpm
mozilla-nss-1.7.3-17.i386.rpm
mozilla-nss-1.7.3-17.x86_64.rpm
mozilla-nss-devel-1.7.3-17.x86_64.rpm
mozplugger-1.6.2-1.x86_64.rpm
Here mozilla-nspr and mozilla-nss are for both architectures - the problem
is: If one builds updates for x86_64 how does one easily determine what
packages that also must be created for i386?
The building is controlled by what devel package files it finds. So if
you only have devel packages for x86_64 installed, then it just works.
I have problems creating the i386 packages anyway, for example:
# setarch i386 rpmbuild --target i386
Clearly something triggers setup for the wrong platform in this case, at
configure looks in the lib64 directories.
This "works" though:
# rpmbuild --target i386 --rebuild mozilla-1.7.5-3.src.rpm
However the resulting rpm is not okay at all:
# rpm -qpl mozilla-nspr-1.7.5-3.i386.rpm
/usr/lib64/libnspr4.so
/usr/lib64/libplc4.so
/usr/lib64/libplds4.so
Life on the combined x86_64 / i386 architecture seems a bit confusing to me so far :-(
I fixed this issue by compiling i386 stuff on a i686 box at work. Pretty
much the only things I wanted i386 were mozilla and galeon packages.
Other things like mplayer I just installed the i386 version with yum
from a repository.
I have libonobo is installed for both 32bit and 64bit. One of the files
in the packages in /usr/libexec/bonobo-activation-server. It is a 64bit
executable. It tries to
load /usr/lib64/bonobo/servers/GNOME_Galeon_Automation.server for the
32bit galeon which puts it in /usr/lib. So it isn't search both /usr/lib
and /usr/lib64 like it should. This also brings up the issue of a lot of
bad placement. GNOME_Galeon_Automation.server is a text file, so
shouldn't it be in /usr/share or something else anyway. When I asked a
galeon developer he said, yes, but that is where bonobo expects it.
A galeon developer told me 32bit gtk programs on an FC3 x86_64 system
were completely broken. When I asked for detail, he said that 32bit gtk
programs trying to use libpixbuf would try to load 64bit themes.