Anand Kumria <[EMAIL PROTECTED]> cum veritate scripsit: > > Well, to elaborate a bit more, a ladspa plugin package would not depend on > > any shared library, or sometimes libc/libm. But that would not be a very > > informative dependency information. Such a package would usually be > > useful only when there is a ladspa-aware sound processing program using > > the plugins. Thus, the plugins can depend on ladspa-host, to express that > > kind of dependency. > > Hmm, having ladspa-host is kind of like saying that libc should > declare a dependancy on packages that would find it useful. > > Personally I don't think any ladspa plugins should declare any > depenany but let the hosts pull them in as required.
That might be a better idea. I think a plugin would be nice if it could Enhances: ladspa-host, at least. > > Although there is only one ladspa-plugin available in Debian (ladspa-sdk), > > I am hoping to have "cmt" and swh plugins available too. That would make > I have just done 'cmt' -- so it should be available shortly. I can see > the value in having ladspa-plugin though. I'll modify my package to > provide that. That would be nice. Currently ecasound / ladspa-sdk have them. > > > > This is my explanation as to why these virtual package names are required. > > I can see the value in ladspa-plugin but not ladspa-host myself. Hmmm... ladspa-plugin is definitely needed. I would guess ladspa-host would be not too interesting. Providing ladspa-plugin and Suggesting ladspa-plugin would be enough to signify what I have explained. I agree ladspa-host is not really a required name. -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GE d+ s:- a-- C+ UL++++ P- L+++ E W++ N o-- K- w++ O- M- V-- PS+ PE-- Y+ PGP+ t-- 5 X-- R* tv- b+ DI- D++ G e h* r% !y+ ------END GEEK CODE BLOCK------
