Bug 1026504 - Broken conflicts/obsoletes in 3.3.8-16
Broken conflicts/obsoletes in 3.3.8-16
Product: Fedora
Classification: Fedora
Component: procps-ng (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jaromír Cápík
Fedora Extras Quality Assurance
Depends On:
Blocks: 1026511
  Show dependency treegraph
Reported: 2013-11-04 14:50 EST by James Antill
Modified: 2016-01-31 20:59 EST (History)
2 users (show)

See Also:
Fixed In Version: procps-ng-3.3.8-17.fc21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-07 08:16:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Antill 2013-11-04 14:50:57 EST
Description of problem:

 procps-ng-3.3.38-16 has:

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.
Comment 1 Jaromír Cápík 2013-11-05 11:02:16 EST
Hello James.

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 ...

That means:
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.
Comment 2 Jaromír Cápík 2013-11-05 11:05:41 EST
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.
Comment 3 James Antill 2013-11-06 10:45:02 EST
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.
Comment 4 James Antill 2013-11-06 10:46:45 EST
(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.
Comment 5 Jaromír Cápík 2013-11-07 07:17:05 EST
Ok then. Going to do that.

Note You need to log in before you can comment on or make changes to this bug.