Bug 16303 - rpm "freshen" behaves differently in 3.0.5
Summary: rpm "freshen" behaves differently in 3.0.5
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 6.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-08-15 23:57 UTC by jrjohns
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-08-16 01:50:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description jrjohns 2000-08-15 23:57:26 UTC
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}

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-16 00:16:45 UTC
Look at the script /usr/lib/rpm/freshen.sh from rpm-3.0.4 and earlier to see how
test if a package needs freshening (i.e. package with same name is already
and later version is available).

Comment 2 jrjohns 2000-08-16 01:45:57 UTC
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
# 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 $?

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
# rpm --freshen pam-0.68-10.i386.rpm
# echo $?

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 $?

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

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-16 01:50:24 UTC
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 18:50:37 UTC
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.