Bug 1074250 - rfkill man page file conflicts
rfkill man page file conflicts
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P5 - None : Normal with 1 vote (vote)
: ---
Assigned To: Stanislav Brabec
E-mail List
:
Depends on: 1074672
Blocks:
  Show dependency treegraph
 
Reported: 2017-12-31 15:10 UTC by Wolfgang Rosenauer
Modified: 2019-03-04 10:19 UTC (History)
8 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Rosenauer 2017-12-31 15:10:04 UTC
During last TW snapshot upgrade the following error occurred:

Detected 1 file conflict:

File /usr/share/man/man8/rfkill.8.gz
  from install of
     util-linux-2.31-1.1.x86_64 (openSUSE-20171213-0)
  conflicts with file from package
     rfkill-0.5-8.6.x86_64 (@System)
Comment 1 Peter Sütterlin 2017-12-31 22:22:49 UTC
Yp, same here.
Looks like the program has been moved from a separate package to util-linux, but the old package isn't obsoleted/removed...
You'll also see that you now have both /usr/sbin/rfkill and /usr/bin/rfkill....
Comment 2 Christian Boltz 2018-01-01 11:52:57 UTC
Assigning to util-linux bugowner, and CC'ing rfkill maintainer.

Stanislav and Jiri, can you please sort this out? ;-)
Comment 3 Antoine Belvire 2018-01-01 15:31:35 UTC
Already submitted a fix to util-linux: https://build.opensuse.org/request/show/561007.

Also submitted a delete request for openSUSE:Factory/rfkill: https://build.opensuse.org/request/show/560984.
Comment 4 Bernhard Wiedemann 2018-01-01 20:14:39 UTC
did you notice that the old package had these:
/usr/lib/systemd/system/rfkill-block@.service
/usr/lib/systemd/system/rfkill-unblock@.service
Comment 5 Antoine Belvire 2018-01-02 09:43:53 UTC
(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.
Comment 6 Frank Krüger 2018-01-02 17:59:08 UTC
(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?
Comment 7 Antoine Belvire 2018-01-02 18:59:34 UTC
(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.
Comment 8 Frank Krüger 2018-01-02 19:20:30 UTC
(In reply to Antoine Belvire from comment #7)
> (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.

Nice advice to "learn packaging". To summarize, current version of rfkill, which contains rfkill-(un)block@.service, will be dropped in favour of util-linux, which does not provide theses services.
Comment 9 Antoine Belvire 2018-01-02 19:31:34 UTC
(In reply to Frank Kruger from comment #8)
> Nice advice to "learn packaging".

(I didn't mean to be offensive. Packaging can be fun :-))
Comment 10 Stanislav Brabec 2018-01-03 17:47:20 UTC
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.
Comment 11 Antoine Belvire 2018-01-03 19:40:57 UTC
> 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

If what you're saying is true (that this may confuse the solver) then the wiki should be updated: https://en.opensuse.org/openSUSE:Package_dependencies#Merging_a_package.

Also, Fedora does exactly the same thing (self obsoleting): http://pkgs.fedoraproject.org/cgit/rpms/util-linux.git/tree/util-linux.spec.
 
> I propose to fill a drop request for rfkill in Factory

Already done, see comment 3 ;-)

> then revert to
> release based conflict, but increment the version to the last rfkill release
> number even seen + 1.

So you mean:

Obsoletes: rfkill < 0.5-8.7
Provides: rfkill = 0.5-8.7

CCing dimstar since he's not fan of "Obsoletes:" with revision number and he had made a comment on my submit request about that (https://build.opensuse.org/request/show/561007).
Comment 12 Stanislav Brabec 2018-01-03 19:53:19 UTC
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
Comment 13 Frank Krüger 2018-01-03 21:09:32 UTC
(In reply to Stanislav Brabec from comment #12)
> rfkill: https://build.opensuse.org/request/show/561458

Thank you for taking over and adding rfkill-(un)block@.service to util-linux.
Comment 14 Dominique Leuenberger 2018-01-04 08:05:50 UTC
(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)
Comment 15 Stanislav Brabec 2018-01-04 15:23:45 UTC
Dominique Leuenberger: Thanks for explanation.

I will revert and update all similar cases in the spec.

And what about

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

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.

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?
Comment 16 Dominique Leuenberger 2018-01-04 15:33:01 UTC
(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.
Comment 17 Stanislav Brabec 2018-01-04 16:02:01 UTC
Dominique Leuenberger, reply to comment 16:

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

The file conflict exists between the old build of bash-completion that provided rfkill completion file in the past, and util-linux, which provides it now.

> 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:

Conflicts: foo <= last_version_of_foo_that_contains_the_conflicting_file

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.

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

 File conflict of su and kill (up to 12.3 and SLE11).
# It should be coreutils < 8.21-4, but coreutils provide Release-less symbol.
Conflicts:      coreutils < 8.21
# File conflict of sulogin and utmpdump (up to 12.3 and SLE11).
Conflicts:      sysvinit-tools < 2.88+-87
# rfkill conflicts of completion files with <= Leap 42.3 and < SLE15.
Conflicts:      bash-completion <= 2.7-1.3
# The preset is provided by the presets branding package since 0.4 (bsc#1012850) and since 12.2 in SLE (boo#1029775)
Conflicts:      systemd-presets-branding < 12.2

> 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

So only in case of file move by the Online Update, we really need such conflict to ensure that both packages are updated together.
Comment 18 Dominique Leuenberger 2018-01-04 16:11:27 UTC
(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...
Comment 19 Stanislav Brabec 2018-01-04 17:13:43 UTC
Thanks for explanation.

Removed the uneeded stuff (release based obsoletes, file move conflicts):

util-linux: https://build.opensuse.org/request/show/561705
Comment 20 Stanislav Brabec 2018-01-25 16:15:42 UTC
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.
Comment 21 Stanislav Brabec 2018-11-22 16:34:13 UTC
Upstreaming in progress:
https://marc.info/?t=154283074100002&r=1&w=2

Once it will be accepted, the last step will be:
During the next version upgrade, drop rfkill-block@.service and rfkill-unblock@.service from spec file and use upstream version of these files.
Comment 22 Markéta Machová 2019-03-04 10:19:26 UTC
This was fixed and never closed. Thanks, Stanislav.