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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
