On Wed, 28 Jul 2004, David D. Hagood wrote:
> On 07/28/2004 02:08 PM, Jeff Johnson wrote:
>
> > No conversion is possibly in general, as a --repackage is "best effort",
> > there can and will be missing files, changed permissions, more.
> >
> > Go find the original packacge is my recommendation.
> >
>
> I thought the whole idea of the rollback RPM was to capture the state of the
> system before the RPM was installed, to allow restoring the system to that state
> at a later time should the upgrade be found to have a problem.
>
> If there is no way to *apply* the rollback RPM, then it is useless.
>
Yes there is a way. Use the --rollback option. And if you really want to
do something bad:
rpm -Uvh --nodigest repackaged_package.rpm
Will do this, but its evil to do this in general because this will ignore
the fact that this repackaged package was installed within a transaction
set that, unless you were doing --nodeps, had dependencies satisfied, and
it ignores whether or not other transactions may have occured after this.
Really if all you want to do is a downgrade, you should litterally get the
original package, repackaged packages are designed to facilitate a
rollback to certain time.
If you think of an upgrade as a function that transforms your system from
one state to the next, then a rollback is the inverse of that function.
Multilple transactions mean multiple transform functions such that to get
back to time t you need to apply the inverse of the transform function in
the reverse order which they were applied:
t1 = initial upgrade time
Mulitple Upgrades
======================
U1(S1) = S2
U2(S2) = S3
...
Un(Sn) = Sn+1
Rollback to t1
-1
Un (Sn+1) = Sn
-1
Un-1(Sn) = Sn-1
...
-1
U1 (S2) = S1
And this, btw, can get severely borked with opaque scriptlets not taking
into account the possibility of a rollback. Also, a transformation of
system from one state to another can loose information in the new state
such that unless you saved this information aside it you can't get back
to the original state (think of this like a password hash). If all your
doing is restoring files then the repackaged package provides this
extra information, but if your scriptlets are changing configfiles and
such you have to use some means external to rpm to keep this info (I use
rcs, but there are a number of ways to do this).
> Insofar as I can tell, there is no way to invoke the RPM library routines to
> process the rollback RPM.
>
Sure, tell it to ignore digests, but if your doing this with librpm,
better to call RPMRollback() directly. You have to build up an
installArgs structure but its not that hard. See 6 release of my rpm-4.2
SRPM and look at the arbgoal patch. You can find this at:
http://lee.k12.nc.us/~joden/misc/patches/rpm
> I don't want to recreate a package that can be applied to other machines - I
> want to create a package that can be applied *on the machine that created it* to
> undo an upgrade.
That is exactly what the repackaged package will allow, but it was always
meant to be done in the context of --rollback (which really is
RPMRollback()). Again, you can circumnavigate this, but its not IMHO a
very good idea (course Jeff might say my autorollback stuff ain't such a
good idea (-;).
Cheers...james
>
>
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/rpm-list
>
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
