default rpm query format on x86_64

Bernardo Innocenti bernie at
Wed Jun 29 22:54:12 UTC 2005

Tyler Larson wrote:
> Bernardo Innocenti wrote:
>> This program was broken already on multiarch platforms because
>> it would consider an i386 package a candidate for upgrading
>> an x86_64 package.  I've now teached it to consider architectures
>> instead of stripping them away.
> Which brings up a good point--
> x86_64 systems (and perhaps other multiarch platforms) are becoming much
> more common, and the trend will only increase. By keeping the arch out
> of the default query format, we're only encouraging script developers to
> ignore package architectures. That's bad.


> It is quite possible that changing the default is the Right Thing to do,
> and would lead to fewer problems altogether down the road--even though
> it may force developers to modify their scripts. Perhaps in the process
> these developers will take a moment to think about how their process
> would work on a  multiarch system.

The easy fix requires a one-line change to specify the query format.
My script required more work because it really needed to consider
the architecture when comparing packages.

> RedHat has a proud history of breaking backward compatibility when the
> circumstances demand. The negative impact of such this change would
> probably be minimal and short-lived, and overall I think it would be
> worth it. However, this sort of change should be made as part of a new
> release. Best to wait till FC5.

I also hope FC5 will introduce the ability to upgrade an i386
system to x86_64.

I did it manually for my workstation and it required just
a single reboot to install the 64bit kernel.

Everything else I could do by forcing RPM to do what I meant
despite I was apparently breaking dependencies and installing
conflicting files.

Now my migration to 64bit is 90% complete.  I sometimes find 
yet another i386 package I forgot to upgrade.  Finding them
all is difficult because they still work fine :-)

  // Bernardo Innocenti - Develer S.r.l., R&D dept.

More information about the devel mailing list