| Summary: | rpm ignores updated packages without updaters? (conflicts+obsoletes procps-ng/sysvinit) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | James Antill <james.antill> |
| Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | ffesti, jzeleny, novyjindrich, packaging-team-maint, rvokal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-07-19 10:33:33 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | 1026504 | ||
| Bug Blocks: | 1026512 | ||
|
Description
James Antill
2013-11-04 20:43:47 UTC
After a fair bit of background info hunting I think I'm able to reproduce this, and yeah it does seem like an rpm bug of the wacko corner case type: With obstest-update package which has: Conflicts: telnet < 1:0.17-58 Obsoletes: telnet > 1:0.17-58 [root@localhost tmp]# rpm -Uvh --test /home/pmatilai/rpmbuild/RPMS/noarch/obstest-update-0.2-1.noarch.rpm /tmp/telnet-0.17-58.fc20.x86_64.rpm warning: package obstest-update-0.2-1.noarch was already added, skipping telnet-1:0.17-58.fc20.x86_64 error: Failed dependencies: telnet < 1:0.17-58 conflicts with obstest-update-0.2-1.noarch ...which is what I suppose what this bug is about. The fun part is that its order-dependent: [root@localhost tmp]# rpm -Uvh --test /tmp/telnet-0.17-58.fc20.x86_64.rpm /home/pmatilai/rpmbuild/RPMS/noarch/obstest-update-0.2-1.noarch.rpm warning: package telnet-1:0.17-58.fc20.x86_64 was already added, replacing with obstest-update-0.2-1.noarch Preparing... ################################# [100%] So... when the to-be-obsoleted package is processed first, rpm sees the conflicting version as removed and obsoletion proceeds normally. However when the obsoleting package comes first, it skips processing the to-be-obsoleted package because its not to be installed anyway. When conflicts/obsoletes are versioned this way, the conflict appears to remain. BTW this begs the question: if an updated but to-be-obsoleted package itself obsoletes something, should those "obsoleted obsoletes" be considered? If we must consider the erasure side-effect of updated but obsoleted packages, then shouldn't we consider the other side-effects too? Makes my head hurt :) (In reply to Panu Matilainen from comment #2) > BTW this begs the question: if an updated but to-be-obsoleted package itself > obsoletes something, should those "obsoleted obsoletes" be considered? If we > must consider the erasure side-effect of updated but obsoleted packages, > then shouldn't we consider the other side-effects too? Makes my head hurt :) From the yum side I believe we short circuit this already, EG. pkgA: obs: pkgoA pkgB: obs: pkgA pkgC: req: pkgoA ...what we'll end up with is pkgC+pkgB to be installed, and if pkgoA is already installed that'll be "obsoleted" by pkgB (I haven't tested this, but I'm pretty sure and anything else is likely to be a bug :). Either I misunderstand the example or I was talking about something different :) What I meant is, taking the original case here: suppose the updated sysvinit-tools obsoletes something new and unrelated, say, "foo". Should "foo" get removed despite sysvinit-tools itself getting obsoleted? That's what yum does, based on a quick test. Which makes sense in some ways, yet seems a bit odd in others. dnf (via libsolv I assume) behaves entirely differently btw, it refuses to such the nutty update at all: [root@localhost ~]# dnf update /tmp/telnet-0.17-58.fc20.x86_64.rpm /home/pmatilai/rpmbuild/RPMS/noarch/obstest-update-0.2-1.noarch.rpm Resolving dependencies --> Starting dependency resolution --> Finished dependency resolution Error: package obstest-update-0.2-1.noarch obsoletes telnet > 0.17-58 provided by telnet-1:0.17-58.fc20.x86_64 [root@localhost ~]# (In reply to Panu Matilainen from comment #4) > dnf (via libsolv I assume) behaves entirely differently btw, it refuses to > such the nutty update at all: s/refuses to such/refuses to touch/ This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |