http://bugzilla.opensuse.org/show_bug.cgi?id=1074250
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c18
Dominique Leuenberger
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.