let me explain this a little bit, I am in charge of update part of our company product from 32 to 64 bits.

At the end, we should have a 64bits kernel + 32bits applications + some 64bits applications. With this scenario, we deduce I need 32&64bits version of some rpms, mainly dependencies, but the picture turns a bit ugly after I start working with the dependencies.

Supose I have only one program, Program1, that will be 64 bits and the rest of the system 32 bits. This Program1, requires libgcc. Before any stuff is done on the system, I query for my actual libgcc version

$>rpm -qa --queryformat '%{NAME}.%{ARCH}\n' | grep libgcc

And the response:


I go and install the libgcc rpm for 64 bits:

$>rpm -ivh --force --ignorearch libgcc-4.3.2-7.x86_64

But now, after query

$>rpm -qa --queryformat '%{NAME}.%{ARCH}\n' | grep libgcc

I get only one entry, instead of two


If I check the files, the libraries and programs run as expected, so that would not be any trouble... until I want to update our common infrastructure in both versions.

Suppose now the new common package, for example, commonlibraries.i386.rpm and commonlibraries.x86_64.rpm.

If I want to upgrade the commonlibraries.i386, it requires libgcc.i386 and as we could see, only one architecture is reported, after the update x86_64 and, as consequence, the upgrade process fails.

The funny fact is in my workstation, I can get both version,

$ rpm -qa --queryformat '%{NAME}.%{ARCH}\n' | grep libgcc

But on our product, looks impossible to have the same package for multiple architecture(and this happens with some packages, like libgcc but not with others like kerberos5-libraries). Is there any guru out there who had this problem in the past.

I have already read here https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=380441 to run rpm -e --justbd --nodeps PackageName and install afterwards the rpms... but that doesn't work.

1 Answer 1


Finally we achieved our desired migration to 64 bits. The problem looks more like a packaging problem on an old distro than a real 32-64 bits problem.

When I tried to install libgcc without the force, it conflicted with some binaries of the %post macro part, something like post_libgcc_upgrade. So in for each rpm package that conflicted for 32-64 bits, we "lost" that 32 bit package.

At the end I took the whole dependencies from the set of rpm packages, their scripts, and create my own rpm package with different names for the files in conflict, modifying the scripts accordingly. Took some days to gather all the info and tested it properly but was worthy.

Anyway, maybe this is helpful for somebody that is why I post the solution I took.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .