Bug 111071
| Summary: | unexpected removal of package upon upgrade / inconsistent behaviour | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Schwendt <bugs.michael> |
| Component: | rpm | Assignee: | Paul Nasrat <pnasrat> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | axel.thimm, gauret, herrold, jnovy, rdieter |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugzilla.fedora.us/show_bug.cgi?id=1059 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-08-18 08:38:17 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
Michael Schwendt
2003-11-26 23:15:07 UTC
update it is reproducible with plain rpm. use rpm -Uvh not rpm -ivh and the bug is reproducible with normal rpm. If both packages are -Uvh'ed at once, there are no conflicts or removals: # rpm -Uvh gpgme03-0.3.15-0.fdr.2.1.i386.rpm gpgme-0.4.0-0.fdr.2.1.i386.rpm Preparing... ########################################### [100%] 1:gpgme ########################################### [ 50%] 2:gpgme03 ########################################### [100%] # rpm -qa 'gpgme*' gpgme-0.4.0-0.fdr.2.1 gpgme03-0.3.15-0.fdr.2.1 [...] Similary, if "rpm -ivh gpgme*" is run first and then "rpm -Uvh gpgme03*", it works without problems/warnings/errors either. Hmmm, gpgme03 has (afaict)
Provides: gpgme = 0:0.3.15-0.fdr.2.1
So gpgme03 is erased when gpgme is upgraded.
This is the implemented and desired behavior, not gonna change.
What, that you can get different behavior if both are included in same transaction? Yes, update behavior is defined against installed, not added, packages, and including both on same CLI will install both pkgs. IMO, this behavior is certainly unexpected, and annoying in the least. (since it changes behavior from previous versions). What's the point of having separate Obsoletes and Provides tags then? Is Obsoletes predecated? With the new behaviour of upgrading on virtual provides, there is currently no mechanism for having compatibility packages provide a standardized resource that is being required by another package (because they get upgraded upon that exposed resource entity). So any compatibility cycling (think new autoconf/automake) requires rewriting of dependent packages. Instead packages depending on for instance autoconf/automake could simply have had BuildRequires: autoconf >= 2.53, autoconf < 2.59 (similar for automake, libtool, gcc, python, etc.) Ideally packages exitsing in multiple versions would a) either have a common name, but be identified as non-upgradable (like some resolvers deal with "kernel" packages), or b) be uniquified by adding version suffixes to the rpm name-tag of the package, but still provide a common and versioned entity string (e.g. automake14 and automake16 provide automake = ...). a) would require automation within rpm, because keeping an external list of packages to be installed, not upgraded, is a bad bookkeeping practice (this could be something like Provides: never-upgrade, which rpm's upgrade mechanism should respect). b) is broken with rpm >= 4.2.1 because the common entity is taken into package upgrade consideration, removing all older packages. Reopening as this should be reconsidered to fix it again. Rpm 4.4.2.1 reverts the implicit obsoletion on provides behavior. So it's already fixed in rawhide, and update for F7 and FC6 is in updates-testing. |