Dunno if OT. This thread remember me of an old rpm RFE about to doing
the scriptlet arch specific. Is it Perhaps related ? I have forgetten
the details. Best regards
2011/4/17, Michael Schwendt <mschwendt(a)gmail.com>:
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.
--
packaging mailing list
packaging(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging