noarch RPM weirdness
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
> + 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
> 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
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
A reproducer is always good as it means we dont need to guess :)
- Panu -
More information about the Rpm-list