Bug 142250 - --rollback runs erase of first package in transaction first before install
--rollback runs erase of first package in transaction first before install
Status: CLOSED UPSTREAM
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rpm (Show other bugs)
3.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
http://lee.k12.nc.us/~joden/misc/patc...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-08 10:37 EST by James Olin Oden
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-15 18:52:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Non verbose output of test case 18 (3.99 KB, text/plain)
2005-02-07 12:00 EST, James Olin Oden
no flags Details
Verbose output of test 18 (82.61 KB, text/plain)
2005-02-07 12:01 EST, James Olin Oden
no flags Details
Patch to fix this problem (361 bytes, patch)
2005-06-02 21:06 EDT, James Olin Oden
no flags Details | Diff

  None (edit)
Description James Olin Oden 2004-12-08 10:37:59 EST
Description of problem:

A given transaction is ran with N packages to be upgraded.
They all upgrade just fine.   At a later point a rollback is 
performed that matches this transaction.  When the rollback 
transaction is ran it will run in this order:

   erase new 1 as pure erase (instance count 0)
   install old 1 as pure install (instance count 1)
   install old 2 - N as upgrade (instance count 2)
   erase new 2 - N as upgrade (instance count 1)

It appears the 1st install element in the transaction rollback 
transaction does not get associated with the package it is 
replacing. 

Version-Release number of selected component (if applicable):

4.2.1

How reproducible:
Always

Steps to Reproduce:
1) Pull down the lastest version of my rpm-test-harness.
2) Unpack it.
3) Configure system to repackage all erasures (need to add this to my 
test harness...sigh).
4) Run ./init
5) Run ./test 18 and ./test   
Actual results:
Test 18 installs package test-1-1, upgrades it to test-1-2.
It then rolls it back to test-1-1.  You will see the test-1-2 get 
erased first and the its instance count show up as 0 and then test-1-
1 will get installed with an instance count of 1.

Test 19 installs test-1-1, test2-1-1 and test3-1-1.  It then upgrades 
them to VR = 1-2 of each.  Finally it rolls them back to VR = 1-1.
When it runs the rollback transaction it will look like this:

   erase test-1-2 instance count 0
   install test-1-1 instance count 1
   install test2-1-1 instance count 2
   install test3-1-1 instance count 2
   erase test2-1-2 instance count 1
   erase test3-1-2 instance count 1

Expected results:
With 18:
   install test-1-1 instance count 2
   erase test-1-2 instance count 1

With test 19:

   install test-1-1 instance count 2
   install test2-1-1 instance count 2
   install test3-1-1 instance count 2
   erase test-1-2 instance count 1
   erase test2-1-2 instance count 1
   erase test3-1-2 instance count 1

Additional info:
This appears to happen with the version of RPM that shiped with RH 9 
also.  I have not tested it on any releases of Fedora.

I will not be able to submit a patch for this for a couple of weeks, 
but I just wanted to let you know about it for now.  I can't believe 
I never noticed it before, but my test harness only had tests for 
autorollbacks and not regular rollbacks...sigh.

Also, I am setting the priority to high, though I know RedHats take 
on all things rollback, so simply take that as how I feel about the 
bug.  For those using rollbacks it really is problematic though it 
depends on what package ends up getting purely erased.  If its bash 
or glibc then the sky has effectively fallen.  Most other packages 
will not cause any problems what so ever.
Comment 6 James Olin Oden 2005-02-07 12:00:42 EST
Created attachment 110729 [details]
Non verbose output of test case 18

Test case produced by latest rpm-test-harness, using test case 18 which
upgrades one package, and then does a --rollback of that package.
Comment 7 James Olin Oden 2005-02-07 12:01:27 EST
Created attachment 110730 [details]
Verbose output of test 18
Comment 8 James Olin Oden 2005-06-02 21:06:45 EDT
Created attachment 115121 [details]
Patch to fix this problem

This seems to fix the problem.	Basically, in depends.c the code that bubbles
the install elements to the top of the list of rpmte's and bubbles the erase
elements to the bottom seemed to have a very general flaw (other than it seems
far more complicated than it needs to be...I know I'm probably missing
something, but wow that code seems to go about things the hard way). 
Basically, after adding much debug output and much head scrathing I realized
the section of code that was supposed to bubble the installs to the top of the
list was catching the first erase.  Since the "package key" on erases is set to
-1 I made it continue in the loop not only if the rpmte had already been
cleared from the original list, but if the package key was -1.	 All, test
harness tests in CVS head seem to work.  I am doing an overnight run and if I
have any problems I will let you know.

BTW, as mentioned I am pretty sure that this is a bug in every version of rpm
since AS 2.1 days.  It definately fails in the head.   If you think the patch
looks good I will apply to the HEAD.

Thanks...james
Comment 9 Paul Nasrat 2005-06-02 21:40:44 EDT
James,

Thanks for the patch - if you don't mind I'd like to test it out a little
tomorrow before feeding back to you on.
Comment 10 Jeff Johnson 2005-11-15 18:52:45 EST
Fixed in rpm-4.4.3.

Note You need to log in before you can comment on or make changes to this bug.