Comment # 18 on bug 1074250 from Dominique Leuenberger

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