http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c2 Christian Boltz <suse-beta@cboltz.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jslaby@suse.com, | |suse-beta@cboltz.de Assignee|bnc-team-screening@forge.pr |sbrabec@suse.com |ovo.novell.com | --- Comment #2 from Christian Boltz <suse-beta@cboltz.de> --- Assigning to util-linux bugowner, and CC'ing rfkill maintainer. Stanislav and Jiri, can you please sort this out? ;-) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c5 --- Comment #5 from Antoine Belvire <antoine.belvire@opensuse.org> --- (In reply to Bernhard Wiedemann from comment #4)

did you notice that the old package had these: /usr/lib/systemd/system/rfkill-block@.service /usr/lib/systemd/system/rfkill-unblock@.service

If someone relies on them, I guess he just has to add them to util-linux. He also would have to change ExecStart because rfkill is now in /usr/bin, not /usr/sbin. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c7 --- Comment #7 from Antoine Belvire <antoine.belvire@opensuse.org> --- (In reply to Frank Kruger from comment #6)

(In reply to Antoine Belvire from comment #5)

...

(In reply to Bernhard Wiedemann from comment #4)

...

did you notice that the old package had these: /usr/lib/systemd/system/rfkill-block@.service /usr/lib/systemd/system/rfkill-unblock@.service

If someone relies on them, I guess he just has to add them to util-linux. He also would have to change ExecStart because rfkill is now in /usr/bin, not /usr/sbin.

Since I am a mere user, what do I have to do to "just add" rfkill-(un)block@.service to util-linux?

Ask a packager to do it for you (or learn packaging ;-)). If it's really useful, maybe ask upstream to add these files in their sources. Sorry, I'm out now, leaving it to util-linux package maintainer. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c9 --- Comment #9 from Antoine Belvire <antoine.belvire@opensuse.org> --- (In reply to Frank Kruger from comment #8)

Nice advice to "learn packaging".

(I didn't mean to be offensive. Packaging can be fun :-)) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c10 --- Comment #10 from Stanislav Brabec <sbrabec@suse.com> --- 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: That provides symbol rfkill version 0.5. Provides: rfkill = 0.5 That obsoletes anything that provides rfkill version <= 0.5, i. e. both rfkill package and util-linux. Obsoletes: rfkill <= 0.5 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). 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. Regarding /usr/lib/systemd/system/rfkill-block@.service /usr/lib/systemd/system/rfkill-unblock@.service It makes sense to add them to util-linux. As integration of rfkill to util-linux was an upstream decision, we should probably add these services to the upstream as well. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c12 --- Comment #12 from Stanislav Brabec <sbrabec@suse.com> --- I hope that rfkill-0.5-8.6 is the last build before dropping and using symbol version 0.5-8.7. rfkill: https://build.opensuse.org/request/show/561458 util-linux: https://build.opensuse.org/request/show/561464 Antoine Belvire: Factory team rejected several my commits with "<=", so I assume that it is a problem somewhere. I am using release based Obsoletes with "<" now. We can ask Factory team. util-linux did not increment rfkill version while integrating it: # rpm -qf /usr/bin/rfkill util-linux-2.31-1.1.x86_64 # rfkill --version rfkill 0.5 So we cannot use e. g.: Provides: rfkill = 0.5.1 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c14 --- Comment #14 from Dominique Leuenberger <dimstar@opensuse.org> --- (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) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c16 Dominique Leuenberger <dimstar@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(dimstar@opensuse. | |org) | --- Comment #16 from Dominique Leuenberger <dimstar@opensuse.org> --- (In reply to Stanislav Brabec from comment #15)

# rfkill conflicts of completion files with <= Leap 42.3 and < SLE15. Conflicts: bash-completion <= 2.7-1.3

scine rfkill no longer existst, the conflicts would have more chances to survive in bash-completion (conflicts: rfkill <= 0.5); the same issue as above: once rfkill 0.5 would be reintroduced, this conflicts would be in the way (but again, release of bash-completion is unspecific: 42.1: verison 2.1, so ok 42.2: 42.3: Leap 15: 2.7-lp150.1.5 (even 1000 checkins later, this will be < 2.7-1.3) SLE-15:GA: 2.7-1.5 (at this time)

bash-completion continues to exist and it did not get a version update. Just a new build of bash-completion contains one file less, and the old build conflicts with the new util-linux.

There is no real universal answer I'm afraid. Moving files between packages will only work reliably (ever) if both packages are updated 'together' (sort of what we expect in TW, since we formally only support zypper dup, so all packages are updated together); from one release of Leap/SLE to the next, the same is true. And I sure hope we won't do such file moves as maintenance updates.

Do we need some packaging-level help in Leap 15 to perform a seamless update with a file moved from one package to another? Is it already implemented in Leap 12?

In essence we can 'ignore' it for Leap N to Leap N+1, since, as mentioned above, the only supported upgrade path is zypper dup (or upgrade from the DVD, which das also a dist-upgrade); the result being that all packages are being updated together. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c18 Dominique Leuenberger <dimstar@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(dimstar@opensuse. | |org) | --- Comment #18 from Dominique Leuenberger <dimstar@opensuse.org> --- (In reply to Stanislav Brabec from comment #17)

...

In essence we can 'ignore' it for Leap N to Leap N+1, since, as mentioned above, the only supported upgrade path is zypper dup (or upgrade from the DVD, which das also a dist-upgrade); the result being that all packages are being updated together.

So you say that if it is a distro upgrade (or TW), it is OK to move file from one package to another, and it does not need a special packaging help like:

as long as rfkill update (or removal) and util-linux and bash-completion are all in the same 'zypper transaction', the conflict is settled

Conflicts: foo <= last_version_of_foo_that_contains_the_conflicting_file

As you found out: there is no reliable way to do this right (just look at current SLE15 staging, where the release numbers are again different)

I was being afraid of a risk that zypper dup or zypper up will complain on a file conflict instead of seamless update or that it will do something wrong.

As long as you have to rely on %{release}, you can be sure it's not working as expected. If you can rely solely on %{version}, it can be welcome additions (but most often are only interesting during the devel project times)

If it is smart enough nowadays, I can remove many conflicts in the util-linux package:

Assuming that we don't care for people installing this core-utils package on such old systems, we should indeed be able to clean those things up (and util-linux is in Base:System - explicitly NOT targetting old (open)SUSE releases)

...

And I sure hope we won't do such file moves as maintenance updates.

We already did it in Leap:

# File conflicts of completion files with <= Leap 42.1 and <= SLE12 SP1 (fixed by SLE12 Update, boo#977259#c3). Conflicts: bash-completion <= 2.1-10

as maintenance update or between Service Packs? at least in a released/maintained product, the release tags are a bit 'better known' - but as long as there is no special casing for SLE/Leap, it's 'broken' (the sources are shared between SLE/Leap, but the rebuild counters are not in sync; not even the checkin counters, as there can easily be two commits piled up in SLE until it's commited to Leap)

So only in case of file move by the Online Update, we really need such conflict to ensure that both packages are updated together.

Right - and much more care to have the right release set to ensure this works in all scenarios as expected... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c20 --- Comment #20 from Stanislav Brabec <sbrabec@suse.com> --- It is fixed now. Regarding the self obsoletes. The check for that is still present in the rpmlint. I opened bug 1077643 to discuss removal of the confusing check. The remaining issue: Upstream rfkill-block@.service and rfkill-unblock@.service. -- You are receiving this mail because: You are on the CC list for the bug.