Red Hat Bugzilla – Bug 78860
rpm mishandles upgrade to same-version but different package
Last modified: 2008-05-01 11:38:04 EDT
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): rpm-4.2-0.12 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:
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.
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.
> 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).