Overview
Why not https://lib.openmpt.org/libopenmpt/2020/04/14/release-libopenmpt-modplug-0.8.9.0-openmpt1/ ?
That produces libopenmpt_modplug not libmodplug. All the other distributions have libmodplug, I can vaguely remember it in openSUSE as well, was most probably deleted in favor of the one provided by libopenmpt.
I have checked the ABIs.
First, libmodplug-0.9.8's libmodplug.so.1 against libopenmpt-0.4.12's libmodplug.so.1:
» abidiff $a/libmodplug.so.1 $b/libmodplug.so.1 [...] 3 Removed function symbols not referenced by debug info: _ZN10CSoundFile13InitializeDSPEb _ZN10CSoundFile14ProcessMonoDSPEi _ZN10CSoundFile16ProcessStereoDSPEi
Well that's a great start :-/ so libopenmpt was binary incompatible all along. But no one noticed, so openmpt has that going for it.
Now, libopenmpt-0.4.12's libmodplug.so.1 against libopenmpt-modplug-0.8.9.0's libopenmpt_modplug.so.1:
» abidiff $b/libmodplug.so.1 $c/libopenmpt_modplug.so.1 ELF SONAME changed Functions changes summary: 0 Removed, 0 Changed, 0 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable SONAME changed from 'libmodplug.so.1' to 'libopenmpt_modplug.so.1'
So no ABI change there. This suggests that if libopenmpt-modplug was built with the right SONAME, we would have the same situation as a few days ago. Sounds like a plan?
I was looking for a quick clean solution I also dislike long names, somebody else is welcome to create libopenmpt_modplug1 and provide libmodplug1 Have a look at the git fork https://github.com/Konstanty/libmodplug, it is a currently active fork of the original libmodplug
The libopenmpt_modplug also has this option: --enable-libmodplug Enable libmodplug replacement library based on libopenmpt. WARNING: This will replace your current libmodplug installation. CAUTION: The emulation of the libmodplug interface is not complete as libmodplug exposes lots of internal implementation details. If any of those is used by an application, the emulation via libopenmpt will fail and/or crash.
I was stupid not to search for libmodplug in openSUSE it's last days were in Leap:42.3:Update using the github version. modplug is very old and it's only use is for converting music that was made in the 90s but it's nice to have it around. It still builds with gcc10
Well even for 90s music, one can use openmpt or xmp or something :-)
Request History
plater created request
Use openSUSE:Leap:42.3:Update's package
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
dimstar_suse added as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:104"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:adi:104"
licensedigger accepted review
ok
jengelh accepted review
dimstar added dimstar_suse as a reviewer
abi incompatible - better go with the openmpt wrapper that was being split out
dimstar_suse accepted review
Works for me - but needs to be staged together with libopenmpt - as both produce the libmodplug1 sub package (with a random one being published in the FTP tree - clearly not what we want)
dimstar_suse accepted review
Unstaged from project "openSUSE:Factory:Staging:adi:104"
dimstar_suse added factory-staging as a reviewer
Being evaluated by group "factory-staging"
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.
See sr#812414 which removes libopenmpt's devel requirement of libmodplug
Somehow I'd also be in favor of the split-out libmodplug from the openmpt source; so essentially it's the same compat library we had all along - without the abi incompatibility reported by @jengelh by stepp;ing back to this version of libmodplug
I've investigated all of the other distros and they use the sourceforge package. Debian has both libmodplug and libopenmpt-modplug. The fact of the matter isn't the abi differences between libmodplug and libopenmpt-modplug but which one the developers used to build their packages with. I think they used the official one not the mpt emulation layer one. If you had read my comments in the prior request you would have seen openmpt's warning about building libopenmpt-modplug as libmodplug.
you mean
That's kinda obvious and intentional - it's what our old libopenmpt package did as well already. So in fact we DID replace the legacy libmodplug a long time ago.
Reverting back to that code ofl ibmodplug is just inferior to keep on using the now split-out libopenmpt-modplug. Keeping the libmodplag wrappen on the new openmpt-modplug is just natural evolution from the existing openmpt package
But we have you as the maintainer - so for me it's ok to move (back) to libmodplug
Staging it together with libopenmpt - if they happen to be checked in async we would have duplictae builds of libmodplug1, which can cause even more damage
See sr#812414 that's the libopenmpt without libmodplug. I've slapped together libopenmpt-modplug as well in case somebody need the openmpt version.
+3. good approach.