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