Overview
Request 831052 accepted
- Created by WernerFink
- In state accepted
- Supersedes 831015
I still disagree… This specific approach doesn't bring anything but complexity imho, compared with generic approach from guidelines.
Request History
WernerFink created request
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
RBrownSUSE set openSUSE:Factory:Staging:B as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:B"
RBrownSUSE accepted review
Picked "openSUSE:Factory:Staging:B"
dimstar accepted review
dimstar_suse accepted review
Staging Project openSUSE:Factory:Staging:B got accepted.
dimstar_suse approved review
Staging Project openSUSE:Factory:Staging:B got accepted.
dimstar_suse accepted request
Staging Project openSUSE:Factory:Staging:B got accepted.
That can hardly solve the issue:
this 'fixed' %postun script will only ever run when THIS package has been installed and is then removed (explicitliy or upgrade)
until then, %postun script of the previously installed man package will run
so essentially, this does not what you expect it to do
The move of it to postun is nevertheless correct of course - just it won't address the issue seen by upgraders during the libexecdir move
Hi @dimstar, you're correct that the added %postun section itself does not fix the bug. It is for preventing it if/when we change the alternative path again in the future.
To actually fix the bug, the existing %post section suffices now. Indeed
update-alternatives --install …cleans non-existing paths. Same reason why forcing re-installation of the package fixes the issue.(%post didn't suffice on the update that changed the path because %post of new package is executed before old package removal: So old path still existed at that time.)
So to sum up: Any update on this package would fix the bug… Let's just prevent it from happening in the future ;-)