noarch RPM weirdness

Panu Matilainen pmatilai at laiskiainen.org
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 
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Syntax (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