On Wed, 13 Jul 2005, James Olin Oden wrote: > On 7/13/05, R P Herrold <herrold at owlriver.com> wrote: >> it scarcely matters -- rpm rollback is a essentially >> unattainable mirage, due to the unbounded nature of %pre and >> %post actions possible. >> > I wouldn't go that far (though obviously I understand the issues from > the previous email). My goal with autorollback and a few patchs to > the regular rollback code was to make it possible to rollback > (automatically) a failed upgrade. That said scriptlets may in some > cases need changing to work properly/intuitavily in a > rollback transaction. and within that limited scope, it may well work. I can easily think of the circumstance that is does not -- the 'upgradeany' transition from (RHEL|CentOS-)3 [2.4 kernel, modutils, and friends] to (RHEL|CentOS-)4 [2.6, etc] is a one way trip as to the general, used for a while install, case, in almost all circumstances. In a narrow scope, with strong Change Management, and defined Sepcifications and Requirements, it should be possible to audit and stabilize the relevant scriptlets. Say I was rolling out 20k units in a telephony control application, ** without on-host end user level application services needed **, it could be done. But in working through a cost-benefit analysis recently on a project of similar scale, I think I pretty throughly convinced the proponent of a 'rollback' approach, that I could automatedly rip out and re-provision and re-configure more consistently, cheaper, and quicker, than the 'rollback' based approach. It is a fascinating area, JOO is well respected by me for his work in this field, and this topic has been hashed in more detail on the RH hosted rpm-list, and the Duke hosted rpm-devel mailing lists, for those intersted in more detail. - Russ Herrold