On Wed, 13 Jul 2005, James Olin Oden wrote:
On 7/13/05, R P Herrold herrold@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