http://bugzilla.opensuse.org/show_bug.cgi?id=1074250
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c14
--- Comment #14 from Dominique Leuenberger
Regarding the conflict: I added a conflict that contains release part, but probably did not pick high enough release. rfkill did a new rebuild in time between, and release 8.6 was not covered by the symbol.
The change done by Antoine Belvire is not correct as well, as makes util-linux obsoleted by self, which can badly confuse the solver:
I think that confusion of the solver was last seen like what, 10 years ago? This has not been an issue for a long time (other than rpmlint barfing at it); back then, btw, it was more RPM having an issue IIRC, not our solver.
There is no easy solution. Either return back release-based rfkill obsolescence (which is unsafe, as different products can use different release numbers), or set symbol version e. g. to 0.5.0.1 (which is unsafe as well because it will block possible future re-introduction of a separate rfkill package version 0.5).
Any obsoletes based on release is broken by design in OBS: packages are being branched and linked around; the release is in no relation already between the devel project and openSUSE:Factory. And just to make things fun: openSUSE:Leap:42.1 -> rfkill-0.5-11.2 (hence, your upgrade path is broken) openSUSE:Leap:42.2 -> rfkill-0.5-12.4 openSUSE:Leap:42.3 -> rfkill-0.5-14.1 Re-adding a version 0.5 of rfkill to TW would reset the release to -1.1 - so just reintroducing the package would not work in any case without removing the obsoletes on the current rfkill variant. I have the feeling you're over-engineering here.
I propose to fill a drop request for rfkill in Factory, then revert to release based conflict, but increment the version to the last rfkill release number even seen + 1.
rfkill is gone from TW by now (which also means there is a weakremover in the product) -- You are receiving this mail because: You are on the CC list for the bug.