[Fedora-packaging] Upgrade scriptlet

[Michael Schwendt]

On Sun, 17 Apr 2011 13:02:12 +0300, VS wrote:

> >>> $1>=1 for %postun would not be well-defined, btw.
> >>
> >> How so?
> > 
> > That $1 is <=1 in %postun, and hence checking for >=1 includes
> > a non-existing condition.
> 
> $1 can be > 1 in %postun when there are parallel installations involved,
> for example when upgrading installed foo-1.0.i686 and foo-1.0.x86_64
> packages to foo-1.1.i686 and foo-1.1.x86_64.

What needs a fix then? The existing documentation (and any %postun
scriptlets that do $1 -eq 1 to check for an upgrade) or RPM?
And which %postun is executed first? i686 or x86_64?

Similar question wrt earlier your %post multiarch example:

> For example if you install foo.i686 first, then later foo.x86_64:
> at the time foo.x86_64's %post runs, $1 will be 2 in it even if nothing
> is actually being upgraded.

Doesn't that break arch-specific scripts like the following?
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GIO_modules

| %postun
| gio-querymodules-%{__isa_bits} %{_libdir}/gio/modules &> /dev/null || :
|
| %post
| if [ $1 -eq 1 ] ; then
|     # For upgrades, the cache will be regenerated by the new package's %postun
|     gio-querymodules-%{__isa_bits} %{_libdir}/gio/modules || :
| fi

%post for the x86_64 would not refresh the cache, because $1 -eq 1 is false.
Is there a %postun call for the old pkg (i.e. the i686 pkg)? If so, that
%postun would refresh the wrong cache due to %_libdir.
Or is there no %postun call because the install is not an upgrade?
Then the cache would not be refreshed at all for the x86_64 install.