Bug 78860

Summary: rpm mishandles upgrade to same-version but different package
Product: [Retired] Red Hat Raw Hide Reporter: Luca Barbieri <ldb>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0CC: mharris, michael
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-12-02 18:12:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Luca Barbieri 2002-12-02 12:26:23 UTC
Description of problem:
When using rpm -U on an RPM with the same version of the currently installed one
but with different contents, RPM first claims that it is already installed and
then claims that paths conflict with the already installed one.

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

How Reproducible:
Every time.

Steps to Reproduce:
1. Modify the SRPM for an installed RPM and rebuild it
2. Build the SRPM and try to install it with rpm -U

Actual Results:
See above.

Expected Results:
It should preferably detect that the packages are different and treat them as if
the new one had a newer version number.
Alternatively it should just claim that it is already installed without checking
paths (like what happens when the RPM is identical to the installed one)

Additional Information:

Comment 1 Michael Lee Yohe 2002-12-02 14:35:29 UTC
This goes against package management philosophy. If you have a package that
supposedly has the same "version number" and "release number" but from different
packagers - then it might possess different paths _and_ patches.  Consider using
the release number much like Mandrake does:

Release:   1custom

This simple modification will differentiate the packages as far as RPM is
concerned so that an upgrade can work out.

This is NOTABUG.

Comment 2 Mike A. Harris 2002-12-02 14:46:01 UTC
Indeed this is not a bug.

What you are attempting to do is simply using RPM incorrectly.
An upgrade of a package to a new one, is by definition a package
that differs in epoch-version-release comparison.  A package is
considered newer if the epoch is higher, or if the version-release
comparison is higher.  RPM will properly refuse to upgrade a package
that does not have a higher e-v-r, and this is specifically intentional
and not a bug.

The simple way to do what you are trying to do, is to bump the
rpm release number in a sensible way to indicate it has been customized.
A common convention used by numerous people inside and outside of Red Hat
is to append a unique identifier onto the release, and an optional
additional number, for example:

Original:  foo-2.3-4
Custom:    foo 2.3-4.mharris.1

This clearly indicates that it is a custom package to you and to others,
and it also allows rpm to upgrade to it.

An alternate way is to use the "--oldpackage" commandline option, which
is generally used to downgrade packages.  While a rebuild of the same
package isn't really a downgrade, it isn't an upgrade either. Also,
by definition, a rebuilt package is supposed to have the release number
bumped up in some manner.  Not doing so is breaking the rules.

I'm closing this as NOTABUG as it is just improper usage of RPM.

Comment 3 Luca Barbieri 2002-12-02 18:12:01 UTC
> RPM will properly refuse to upgrade a package
> that does not have a higher e-v-r, and this is specifically intentional
> and not a bug.
OK, but why does it then check paths (and output error messages) when it has
already decided to not upgrade the package?

This seems unnecessary, unless the goal is actually to tell the user that the
packages are different but then you should replace "conflicts with" with "is
different from" since this is only an information message, not a failure (and
maybe also add an explicit "the version is the same but the packages are
different" message, perhaps along with an hint on a way to force RPM to install
it anyway).