Subject: Packaging LADSPA (was Re: [linux-audio-dev] again: debian tasks for audio needs)
From: Conrad Parker (conradp_AT_cse.unsw.EDU.AU)
Date: Mon Oct 02 2000 - 15:04:49 EEST
On Mon, Oct 02, 2000 at 07:49:04PM +0900, Junichi Uekawa wrote:
>
> I was wondering what has come with LADSPA and Debian, and what's there
> to package. we could have libladspa-dev, libladspa and cmt packages
> out of reference tools.
AFAIK there is no "libladspa". Some reference code comes with the LADSPA
SDK, but I think most apps have their own implementation of the actual
plugin loading etc.
LADSPA itself just defines an API, to which plugins (like the
CMT) and apps conform. ladspa-dev would basically consist of putting
ladspa.h in /usr/include, and installing the development
documentation.
There are some binaries which come with the LADSPA SDK for
manipulating plugins. Unfortunately these have very generic names
(analyseplugin, applyplugin, listplugins) so I'm not sure if the
intention is to install them by default, or just have them available
for developers. These are about all that could be installed as the
"ladspa" package.
The bulk of the work involves packaging plugins and apps.
> One thing that has to be decided is the standard place where LADSPA
> plugins are going to reside in Debian.
> It won't be /usr/local/LADSPA for sure. It's going to be somewhere
> under /usr/lib/ something. We probably can't put it under
> /usr/share/ because LADSPA plugins are platform dependent.
The LADSPA SDK and the CMT makefiles install plugins into
/usr/local/lib/ladspa. The correct place for [a distribution] to
install these would be /usr/lib/ladspa.
Another issue is versioning: ladspa.h (in LADSPA-SDK) declares itself
as "Version 1", which is the API version, not a software version. (see
the "Versioning" section in the libtool info pages for a good
summary of the difference between the two). The tools that come with
the LADSPA SDK, and also the plugins in the CMT, are currently
unversioned. My understanding is that these things need explicit
software versions in order to be packaged, and secondarily that the
plugins themselves should install API-versioned shared libraries,
ie. a LADSPA plugin 'plugin' should install as
/usr/lib/ladspa/plugin.so.1
or even (preferably, IMHO):
/usr/lib/ladspa/libplugin.so.1
(This will also be useful for apps in order to work out which
plugins they can understand, and to allow plugin writers to use
libtool for building ladspa plugins, but these aren't packaging
issues).
Conrad.
This archive was generated by hypermail 2b28 : Mon Oct 02 2000 - 15:28:28 EEST