Red Hat Bugzilla – Bug 1026504
Broken conflicts/obsoletes in 3.3.8-16
Last modified: 2016-01-31 20:59:14 EST
Description of problem:
Conflicts: sysvinit < 2.88-14
Obsoletes: sysvinit > 2.88-14
...I'm not 100% what you want to do here. But my guess is something like:
Obsoletes: sysvinit < 2.89
...does what you want much better.
Atm. if both procps-ng and sysvinit are old then yum will see the conflicts, do an upgrade, then see the obsoletes and remove the upgrader ... and then rpm gets very unhappy with having the old sysvinit being removed as an upgrade without an upgrader ... throws an unfixed conflicts and gives up.
dnf/libsolve sees both and "solves" by removing everything from the transaction and doing nothing.
This is a complicated scenario. Unfortunately procps-ng cannot obsolete sysvinit < 2.89, since it contains more tools than procps-ng adopted.
sysvinit-tools contained several tools .... some of them were adopted by util-linux and one of them (pidof) was adopted by procps-ng ...
procps-ng is not a full replacement of sysvinit < 2.88-14, but it is a full replacement of sysvinit 2.88-14, because that release contains only the remaining pidof tool.
I'm unsure if a better way, how to deal with this exists.
I would let the sysvinit-tools package die and be removed. In that case I could change the Conflicts to unversioned Obsoletes and everyone will be happy. I'm not agains.
Ahh, I see ... I would just go with the multiple obsoletes (Eg. both procps-ng and util-linux obsolete < 2.89), as most of the time people are going to run "yum upgrade" which will install both new versions anyway. And it certainly works better than now where rpm doesn't seem to like anything, unless you run multiple transactions.
For extra points both the new versions of procps-ng and util-linux could conflict with ealier versions of the other one so that even if someone did something like "yum upgrade procps-ng" and there are no requires that would bring in the new util-linux too ... the conflicts would do it.
(In reply to Jaromír Cápík from comment #2)
> I would let the sysvinit-tools package die and be removed. In that case I
> could change the Conflicts to unversioned Obsoletes and everyone will be
> happy. I'm not agains.
Don't do unversioned obsoletes, it works identically to "sysvinit-tools < 2.89" in the case you want ... but if anyone ever wants to reintroduce sysvinit-tools it becomes much harder with an unversioned obsolete.
Ok then. Going to do that.