noarch RPM weirdness

Panu Matilainen pmatilai at
Tue Mar 2 07:40:10 UTC 2010

On Fri, 26 Feb 2010, Eric Chamberlain wrote:

> This may be a simple explanation for all of you out there but it's been 
> confounding me for some time.  It seems as if the behaviour of a noarch 
> RPM is radically different from say an RPM that defines its arch type of 
> i386.
> Example:
> + Create noarch RPM (1.0.0)
> + Install noarch RPM
> + Create another noarch RPM with a least significant point version of one greater than the last (1.0.1)
> + Install new noarch RPM
> Using rpm -Uhv this will attempt to re-install the old version (run post 
> install scripts) and then install the new version over the latest (will 
> also run the post install scripts).  So at the end of the process I'll 
> have two RPM packages 1.0.0 and 1.0.1.
> Now, when I set the RPM to be targeted towards an i386 it will remove 
> the noarch version(s) and leave only the i386 version -- which is what I 
> expected the later noarch RPM to do.  So, just by changing the arch type 
> the RPM behaves as I would expect it to.  Remove the old, install the 
> new.
> I can only conclude that the reason for this is that noarch RPMs behave 
> differently than those that have their arch type defined... that or it's 
> a bug.  This is reproducible in CentOS 5.2 (64-bit) and 5.3 (64-bit).
> So my questions are:
> Although this question is irrelevant, for curiosity's sake: Is this the 
> expected behaviour of a noarch RPM?

No. I'd guess the %post etc scripts in your package aren't taking 
upgrade-case into account and fail, causing the old version to be left 
around. The scriptlets run in somewhat unexpected order on upgrade, see 
for example (and the 
order section below that)

It should behave the same when the architecture changes, but on multilib 
systems (eg Centos x86_64) there are some funny little quirks in there. 
Does the noarch -> i386 upgrade case behave differently if you add
    --define "_transaction_color 0"
to the command line?

> Everything I've read states only that noarch RPMs don't care about the 
> architecture as the program/scripts/documentation packaged in the RPM 
> are architecture independent.  The RPM is only Python and bash scripts. 
> So, I believe I used the right arch type for the RPM.  Please correct me 
> if I'm wrong.

Yes, noarch is the correct arch for architecture independent packages such 
as shell scripts and pure python.

> My next question is how do I go about removing the old noarch package 
> and replace it with the i386 package in the same process?  Preferably 
> I'd like the noarch package to not run any installation scripts... 
> simply get replaced and have the i386 run it's post install scripts. 
> Uninstalling the old noarch package is an option, although not desirable 
> as there are several dependencies to this package -- the sys admin would 
> prefer not to uninstall and reinstall all dependent packages.
> Is "rpm -Uhv new-i386.rpm --force" enough?

--force wont help here. Again I suspect the scripts aren't correctly 
handling the upgrade, and in that case it's probably necessary to 
first remove the old package and then install the newer one.

> Thanks in advance for your help!  I can post a sample spec file if that 
> helps.

A reproducer is always good as it means we dont need to guess :)

 	- Panu -

More information about the Rpm-list mailing list