libopenmpt <-> libmodplug compataibility layer
jcowgill at debian.org
Sun Jan 1 15:57:17 UTC 2017
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:
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the pkg-multimedia-maintainers