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 -
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
