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.
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list
