Re: [linux-audio-dev] discussion about development overlap

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] discussion about development overlap
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Thu Sep 28 2000 - 20:10:11 EEST


On Thu, 28 Sep 2000, Conrad Parker wrote:

>> Linux distro, and then install ecasound from an rpm. I admit this stricts
>> code reuse in many ways (all 3rd party modules like ALSA, aRts,
>> libaudiofile, etc have to be dynamically loaded, etc), but this approach
> eek. You realise you're going to need to duplicate the functionality
> of ld.so, and you're limiting yourself to environments with sane
> dynamic loading (ok if you assume Linux I guess).

Not really, these plugins are linked normally, so I just need one
dlopen()+dlsym(). The same thing as with LADSPA (or any other) plugins.

> In any case those libraries have to be around anyway -- you don't
> buy anything by simply making ecasound.rpm not depend on them,
> they'll still need to exist on the box for ecasound to run. If you

No they don't have to be. Let's take ALSA support as an example. You can
install the ecasound rpm and use ecasound without ALSA (or with ALSA
OSS-emulation without no trouble). If you have a correct (very unlikely
:)) version of ALSA installed, you can also use it, otherwise trying to
use an ALSA input/output will fail (dlopen() fails).

And of course, people can always recompile. It's just that with ecasound,
recompiling takes so god damn long. I have to keep three machines
up-to-date ecasound-wise, and I'd go mad without the rpms. :)

> intend to ship them along with ecasound, you'll find yourself
> playing package maintainer games.

Well, that's something most developers have to do anyway. :(

> In any case the hassle of installing dependencies vanishes when
> people use apt based distributions (such as debian, and RPM based
[...]
> apt-get install ecasound

Yes, this is definitely an improvement, but it won't handle all the cases.
For instance, I can distribute plugins which are linked against
hard-to-get libraries, like for example Paul's libraries, which you can
only get from Quasimodo CVS. apt-get won't get the libraries from there.
:) If people want to use this plugin-x, they don't have recompile
ecasound, just get the libraries from Quasimodo CVS and start using the
plugins.

> Side note -- hackers, get to know your debian maintainers. They're
> *really useful* to talk to about issues like this (how to handle

Yes, this true. I've received some very valuable advices from people
maintaining ecasound rpms for non-Redhat distros. But still, developers
have to make some decisions concerning dependencies. Basicly, you have to
select, what external packages you use, and also, which dependencies are
optional and which are not.

-- 
 . http://www.eca.cx ... [ audio software for linux ] /\ . 
 . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ . 
 . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Sep 28 2000 - 21:38:18 EEST