Bug 78860
| Summary: | rpm mishandles upgrade to same-version but different package | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Raw Hide | Reporter: | Luca Barbieri <ldb> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0 | CC: | mharris, michael |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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: | |
| Embargoed: | |||
|
Description
Luca Barbieri
2002-12-02 12:26:23 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. 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).
|