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