upgrade and downgrade scripts

[John Gardiner Myers]

I'm trying to build RPMs with scripts that handle tasks that need to be 
done on an upgrade or downgrade of a particular package.  For example, 
between version 1.0 and 2.0 there might be a schema change to a 
database.  An upgrade script would need to be run when upgrading from 
1.0 to 2.0.  A rollback script would need to be run when downgrading 
from 2.0 to 1.0.

Both scripts must be in the 2.0 rpm, as 1.0 will have no idea how to 
upgrade to or downgrade from a future version.

The downgrade script must not be run when upgrading from 2.0 to 3.0 and 
the upgrade script must not be run when downgrading from 3.0 to 2.0, so 
the %pre, %preun, %post, and %postun are not useful.  This would appear 
to require triggers.  I have tried in the 2.0 foo.spec:

%triggerin -- foo < 2.0
echo 2.0 triggerin $1 $2
%triggerun -- foo < 2.0
echo 2.0 triggerun $1 $2
%triggerpostun -- foo < 2.0
echo 2.0 triggerpostun $1 $2
%triggerpostin -- foo < 2.0
echo 2.0 triggerpostin $1 $2
%post
echo 2.0 post $1
%postun
echo 2.0 postun $1

With rpm 4.4.2, this results in output that does not appear to 
adequately explained by the documentation:

# rpm -i foo-1.0-1.i386.rpm
1.0 post 1
# rpm -U foo-2.0-1.i386.rpm
2.0 post 2
2.0 triggerin 2 2
2.0 triggerun 2 1
1.0 postun 1
2.0 triggerpostun 2 1
/var/tmp/rpm-tmp.58167: line 2: fg: no job control
2.0 triggerpostin 2 1

The Fedora RPM Guide states "Inside your trigger scripts, $1, the first 
command-line argument, holds the number of instances of your package 
that will remain after the operation has completed."  It seems to me 
that the value "2" given in the triggerun, triggerpostun, and 
triggerpostin should instead be "1", as only the 2.0 instance of the 
package will remain after the uninstallation operation is complete.

The "fg: no job control" error message appears to be some sort of bug.

# rpm --oldpackage -U foo-1.0-1.i386.rpm
1.0 post 2
2.0 triggerin 2 2
2.0 triggerun 1 2
2.0 postun 1

The Fedora RPM Guide states "The second argument, $2, holds the number 
of instances of the target package that will remain after the 
operation."  The documentation is ambiguous as to whether this means the 
number of instances of the target package that meet the version number 
constraint or whether it means the total number of instances regardless 
of the version number constraint.  If it is the former, than the "2" for 
the triggerin should instead be "1".  If it is the latter, the "2" in 
the triggerun should instead be "1".

So experimentation shows that I could use a %triggerun script to do the 
uninstall action, as long as I test the value of either $1 or $2.  I 
worry, however, that this could be adding a bug dependency, where future 
versions of RPM could "fix" the behavior of %triggerun so that it would 
no longer be able to distinguish the upgrade from the downgrade case.