Hi all, As a bit of background, both libmodplug and OpenMPT are descendants of the original ModPlug Tracker. libmodplug was forked in 1999 using the open-source player components of ModPlug, originally to create an XMMS plugin which could play module music. In 2004 OpenMPT (Open ModPlug Tracker) was forked after the rest of ModPlug (including the editor etc) was open-sourced. libopenmpt was added to OpenMPT in 2013 designed to be a replacement of libmodplug.
The API in libopenmpt is rewritten and (according to upstream) is much better than the API from libmodplug. However they provide an optional compataibility layer which allows libopenmpt to be used as a drop-in replacement for libmodplug. They argue that OpenMPT is better quality and much more actively maintained compared to libmodplug. OpenMPT has a FAQ with more information about all this: https://lib.openmpt.org/libopenmpt/#sec_faq Upstream has asked me to enable this compatibility layer. The layer can be configured to work in 2 ways: 1) The first way creates a library with a different SONAME. This installs all the modplug headers and a libmodplug.so symlink but doesn't touch libmodplug.so.1. This requires an "opt-in" at compile time (eg by installing a special package). 2) The second way installs libmodplug.so.1 and is a complete replacement. The ABI is identical so nothing should need to be recompiled. This would need the OpenMPT version to provide libmodplug1 and I think this is more prone to exposing bugs / behavioral differences between the libraries. Are there any opinions about all this? My current thinking is that option 2 is too invasive to be done for stretch (if we want to do it at all), but option 1 might be possible (if it gets through NEW in time). Thanks, James
signature.asc
Description: OpenPGP digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
