Re: auto-rollback install instance count wrong

[James Olin Oden <joden malachi lee k12 nc us>]

On Sun, 10 Aug 2003, James Olin Oden wrote:

> Hi Jeff,
> 
> I just found a bug in my auto-rollback patch.  Appearantly,
> whenever I run the rollback transaction, and an install
> scriptlet for a package being upgraded is ran, its instances 
> is 3.  I actually understand why this happening.  For instances
> if events transpire as so:
> 
> 	p1 installed.
> 	p2 fails.
> 
> Then at that point there are still two headers in db for p1 (provided
> it was being upgraded.  The problem is this will not always be the
> case, for instance:
> 
> 	p1 installed.
> 	p2 installed.
> 	p1 erased (old pkg).
> 	p2 erase fails (old pkg).
> 
> Then in this case the actual instances in the db would be 1 as 
> the erase of the old pkg header has occured.  
> 
> If it was always off, I could figure out a fix quick (even something ugly 
> like creating a global in the psm called autorollback, and doing
> the right thing based on it being true or false), but since the right
> thing depends on how far along things got I am not sure how to tackle 
> this?
>
I think I came up with two alternative methods of dealing with this.  I
would like to run them by you (and anyone else that cares) and see if 
either are preferable.

Both aproaches are a variation on a common them.  What is common is that
I would keep a list of rpm that I had added to the rollback transaction;
this list would contain one boolean value which tracked whether or not
an upgraded rpm had had its previous instances erased yet or not.  
In the psm, where it calculates the instances of a transaction element,
I would then do something like:

	if in an autorollback
		get te_erased_or_not
		instances -= te_erased_or_not

In this way iif I am in an auto-rollback, and the original package header
was not erased, the instance value would be decremented by one, and
if it had had been erased, it would not be decremented.  The end 
result would yield a 2 on an upgraded package, and a 1 on a downgraded
package in the autorollback.

Now, that's all good, but the real question is where do you store the 
list, and how do you let the psm know the transaction it is running is
an auto-rollback transaction as opposed to a regular rollback transaction.
The first question has two possible answers:

	1) make this list live in global space in transaction.c,
	   and have psm access it globally (yuch!).
	2) Add to the rpmts structure a pointer to the list, and
	   dynamically allocate for each rollback transaction.

The first is easier, but not thread safe at all.  The second is harder,
but it caries with it the overhead of having to touch rpmtsCreate to 
allocate the space if needed (or creating some other method to do so),
and touch rpmtsFree to free the space if it has been created.

As to how do you communicate your in an autorollback.  I guess I could
either overload the rollback member I added to an rpmts; I would set it
to 1 if its a plain rollback transaction or 2 if its an autorollback.
At this point it allmost sounds like rpmts, really begins to have a type,
and maybe I should backup and change the rollback element I added to 
something like type, and define a few macros like:  RPMTS_TYPE_NORMAL,
RPMTS_TYPE_ROLLBACK, and RPMTS_TYPE_AUTOROLLBACK.  Course the problem
with this is every other than the psm, the behavior of a rollback, and
an autorollback transaction is the same (i.e. revert back to default best
effort strategy of running transactions).

Anyway, these are all just ideas; please let me know what you think, and 
if any particular path is preferable (or any are particulary heinous (-;).

Many Thanks...james
> Any clues?
> 
> Thanks...james
> 
> 
> 
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@redhat.com
> https://www.redhat.com/mailman/listinfo/rpm-list
>