Comment # 14 on bug 1074250 from Dominique Leuenberger

(In reply to Stanislav Brabec from comment #10)
> 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)