Description of problem: procps-ng has some weird conflicts/obsoletes which ends up with yum giving rpm: procps-ng-3.3.38-13 updated procps-ng-3.3.38-16 updater sysvinit-2.88-13 updated ...where procps-ng-3.3.38-16 conflicts with sysvinit < 2.88-14. Although it's kind of a bad result for the user, I'd expect sysvinit-2.88-13 to be removed and the transaction to happen. But rpm seems to ignore that sysvinit-2.88-13 is being removed and fail due to the conflicts. Adding the depends on, as if the procps-ng package is fixed, this bug will go away.
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.