Overview
Request 966760 accepted
Use gzip -n for bit-reproducible builds (forwarded request 966045 from bmwiedemann)
- Created by WernerFink
- In state accepted
Request History
WernerFink created request
Use gzip -n for bit-reproducible builds (forwarded request 966045 from bmwiedemann)
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
dimstar accepted review
dimstar_suse set openSUSE:Factory:Staging:E as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:E"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:E"
dimstar_suse accepted review
Staging Project openSUSE:Factory:Staging:E got accepted.
dimstar_suse approved review
Staging Project openSUSE:Factory:Staging:E got accepted.
dimstar_suse accepted request
Staging Project openSUSE:Factory:Staging:E got accepted.
That's quite a strange thing to do - the main issue of the bug seems to be that the old package is not <= 2017, but is actually 2017.20170520.svn29741, which is definitively > 2017 (so the obsoleted does not catch it)
OK ... that is indeed a point ... nevertheless it works at update on a SLE-15-SP4
Many things work - not all of them are the correct solution. I think we should strive for the latter though
IMHO, if the real solution is known, we should always opt for it
to be clear: the two have slight different meanings, especially if a package with the same name (and higher version) will ever re-appear (something which is probably not excluded with the texlive packaging) - the conflict might cause even more trouble on future upgrades than changing the obsoletes to < 2018
Other than that, the current implementation relies on a specific behavior of zypper (as a conflict is solvable by removing the old package or not installing the new one - an obsoletes is giving clear instruction that removing the old one is the correct solution the the pkg manager)