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@xxxxxxxxx>: > 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 > -- Inviato dal mio dispositivo mobile -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
