Bug 89857 - IDTXglob() needs to sort by REMOVETID its results
Summary: IDTXglob() needs to sort by REMOVETID its results
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-28 22:43 UTC by James Olin Oden
Modified: 2007-04-18 16:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-29 16:33:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
First patch was not checking if the IDTX was empty (1.19 KB, patch)
2003-06-07 11:43 UTC, James Olin Oden
no flags Details | Diff

Description James Olin Oden 2003-04-28 22:43:16 UTC
Description of problem:
Sometimes when running a rollback I was seeing the current package 
removed without restoring the previous package.  This was consistant
with a given package on a particular system, but not accross multiple 
systems.  As it turned out the problem was that rpmRollback() was 
assuming that that the order that IDTXglob() returned the package
headers from the repackaged packages was in the correct order.  
This was not the case, as IDTXglob() was depending on rpmglob() for the
order of the package headers, when in reality they needed to be sorted

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


How reproducible:
It depends on what state your repackaged package dir is in.  When it
gets in the right state, it fails everytime.

Steps to Reproduce:
I am not sure how to get the repackage directory in the state such that
this occurs, but I suspect it involves upgrading and removing a package,
and then installing it and upgrading again all with the --repackage switch.

Once the repackage package directory is in right state then run a script
like this:

  rpm -e normal
  rpm -Uvh /root/work/build/RPM/RPMS/noarch/normal-1.0-1.noarch.rpm
  echo "Rollback Goal:  $(date +%s)"
  X="$(date '+%m/%d/%Y %H:%M:%S')"
  echo "Rollback Goal:  ${X}"
  sleep 10
  rpm -Uvh /root/work/build/RPM/RPMS/noarch/normal-1.1-1.noarch.rpm
  sleep 5
  rpm -Fvvh --rollback "${X}"

Actual results:
The package is completely removed.  No repackaged packages are added as
install elements to any transactions.

Expected results:
The package would be downgraded (i.e. the repackaged package would have made
it into a transaction as an install element).

Additional info:

Here is the patch that fixes this problem (sorry no doxygen):

--- rpm-4.2/lib/rpminstall.c.delta      2003-04-28 17:43:21.000000000 -0400
+++ rpm-4.2/lib/rpminstall.c    2003-04-28 17:47:01.000000000 -0400
@@ -1050,9 +1050,19 @@
        av[i] = _free(av[i]);
     av = _free(av);    ac = 0;

+    /* Sort by REMOVETID */
+    qsort((void *) idtx->idt, idtx->nidt, sizeof(*idtx->idt), IDTcmp);
     return idtx;

+int IDTcmp(const void * a, const void * b)
+    IDT idta = (IDT) a;
+    IDT idtb = (IDT) b;
+    return (idtb->val.u32 - idta->val.u32);
 /** @todo Transaction handling, more, needs work. */
 int rpmRollback(rpmts ts, struct rpmInstallArguments_s * ia, const char ** 
--- rpm-4.2/lib/rpmcli.h.delta  2003-04-28 17:44:46.000000000 -0400
+++ rpm-4.2/lib/rpmcli.h        2003-04-28 17:45:43.000000000 -0400
@@ -667,6 +667,8 @@
        /*@globals rpmGlobalMacroContext, fileSystem, internalState @*/
        /*@modifies ts, rpmGlobalMacroContext, fileSystem, internalState @*/;

+int IDTcmp(const void * a, const void * b);
 /** \ingroup rpmcli
  * Rollback transactions, erasing new, reinstalling old, package(s).
  * @param ts           transaction set

Comment 1 Jeff Johnson 2003-04-29 16:33:20 UTC
Eeek, yes rpm-4.0.4 had
   return IDTXsort(idtx);
at the end of IDTXglob

Fix in rpm-4.3 CVS momentarily. Thanks for noticing.

Comment 2 James Olin Oden 2003-06-07 11:43:19 UTC
Created attachment 92228 [details]
First patch was not checking if the IDTX was empty

Jeff, you probably don't need this, but just in case someone was using this
patch, the one attached gets rid of a segfault.  I was not checking the whether

the IDTX was empty.  This patch simply does:

   if(as > 0)

and then does the sort.  Course I would highly recommend people using your 
rawhide patched version for this purpose.

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