Bug 78860 - rpm mishandles upgrade to same-version but different package
Summary: rpm mishandles upgrade to same-version but different package
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm
Version: 1.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-02 12:26 UTC by Luca Barbieri
Modified: 2008-05-01 15:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-12-02 18:12:10 UTC

Attachments (Terms of Use)

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).

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