Bug 16303 - rpm "freshen" behaves differently in 3.0.5
rpm "freshen" behaves differently in 3.0.5
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-15 19:57 EDT by jrjohns
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-15 21:50:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jrjohns 2000-08-15 19:57:26 EDT
An unexpected functionality change in RPM 3.0.5 now returns the "no error"
status code 0 when there has actually been an error.

The test I'm performing is:
   rpm --test --nodeps --freshen (some rpm that doesn't need freshening)

The previous version of RPM would generate the following with a status code
of 1:
rpm: no packages given for install

The new 3.0.5 RPM generates no warning and no error.  It exits with "0",
happy as a clam.  This behavior is inconsistent with the prior version of
RPM, and I desire the previous functionality because otherwise I do not
know of a way to determine if a file actually needs freshening.

I have a script which applies new RPMs to my system.  It does some testing
up front to determine if these things need to be applied, by using the
combination of "--test" and "--freshen".  This script breaks with the new
RPM.  Here is a snippet to demonstrate what I need:

(bourne shell)

for eachrpm in `cat LIST_OF_RPMS`; do
rpm --test --nodeps --freshen ${eachrpm} > /dev/null 2>&1
if [ $? = "0" ]; then
rpm --query --queryformat "${querystring}" -p ${eachrpm}
rpm --nodeps --freshen -v -h ${eachrpm}
fi
done

You can see that in the above script fragment, RPMs are tested one by one
to see if an update exists, and if so, certain information is first
queried, and then the RPM is applied.

Please correct the behavior of the RPM or provide an alternative way for me
to determine, in advance of actually performing a "freshen", if an RPM is
going to succeed or fail in freshening!  Otherwise, I cannot perform the
query ahead of the actual freshen operation that applies any particular
given RPM.
Comment 1 Jeff Johnson 2000-08-15 20:16:45 EDT
Look at the script /usr/lib/rpm/freshen.sh from rpm-3.0.4 and earlier to see how
to
test if a package needs freshening (i.e. package with same name is already
installed
and later version is available).
Comment 2 jrjohns 2000-08-15 21:45:57 EDT
There is still a condition left unhandled.

There are four conditions, 3 of them were errors with rpm v3.0.3:

Condition 1:  File needs to be freshened.
Condition 2:  The current version is already installed.
Condition 3:  NO version of this package is installed.
Condition 4:  A newer version of this package is already installed.

I expect status 0 from condition 1.

I can catch conditions 2 and 3 using 'query' as demonstrated in the
/usr/lib/rpm/freshen.sh file.

The fourth condition was always handled completely by RPM, and I can't catch it
using a query operation.  Under rpm v3.0.3, if 'freshen.sh' could not determine
that the file either doesn't apply, or the current version is already installed,
it passed its arguments to 'rpm' as an upgrade operation.

Under rpm v3.0.3, the behavior was as follows:

# rpm -q pam
pam-0.72-20
# rpm --freshen pam-0.68-10.i386.rpm
package pam-0.72-20 (which is newer then pam-0.68-10) is already installed
# echo $?
2

The new v3.0.5 rpm doesn't do that.  It returns no error message and a status of
0.  This case really should be an error condition.

# rpm -q pam
pam-0.72-20
# rpm --freshen pam-0.68-10.i386.rpm
# echo $?
0

Note:  If I try -U, I get the expected response.

# rpm -U pam-0.68-10.i386.rpm
package pam-0.72-20 (which is newer then pam-0.68-10) is already installed
# echo $?
2

The difference in behavior is a result of rolling "freshen" into the rpm program
but not staying consistent with the error handling of an "upgrade" (when freshen
was originally just a front-end to upgrade, and thus inherited its error
conditions).

I do appreciate the quick response and advice, and I hope my above description
clarifies the situation better than the initial report.
Comment 3 jrjohns 2000-08-15 21:50:24 EDT
My output for "rpm -U" for rpm v3.0.5 in the above example isn't precisely
accurate.  The grammatical error of "newer then" present in v3.0.3 was corrected
to say "newer than" in v3.0.5.
Comment 4 Jeff Johnson 2001-12-09 13:50:37 EST
rpm-3.0.5 is no longer supported. Please feel free to open
a new bug against rpm-4.0.3, as --freshen behaves the same way
as it does in rpm-3.0.5.

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