[Bug 1074250] New: rfkill man page file conflicts
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 Bug ID: 1074250 Summary: rfkill man page file conflicts Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: wolfgang@rosenauer.org QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- 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) -- 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#c1 Peter Sütterlin
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c2
Christian Boltz
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c3
Antoine Belvire
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c5
--- Comment #5 from Antoine Belvire
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#c6
Frank Kruger
(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? -- 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
(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#c8
--- Comment #8 from Frank Kruger
(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. -- 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
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
Frank Kruger
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c10
--- Comment #10 from Stanislav Brabec
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c11
Antoine Belvire
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). -- 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
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c13
Frank Kruger
Thank you for taking over and adding rfkill-(un)block@.service to util-linux. -- 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
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#c15
Stanislav Brabec
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c16
Dominique Leuenberger
# 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#c17
Stanislav Brabec
# 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. -- 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
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#c19
--- Comment #19 from Stanislav Brabec
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250#c20
--- Comment #20 from Stanislav Brabec
http://bugzilla.opensuse.org/show_bug.cgi?id=1074250 Bug 1074250 depends on bug 1074672, which changed state. Bug 1074672 Summary: false errors of Factory robot auto-reject all util-linux submissions http://bugzilla.opensuse.org/show_bug.cgi?id=1074672 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com