Bug#96873: virtual-package names, ladspa-host and ladspa-plugin
On Tue, May 22, 2001 at 12:34:48AM +0900, Junichi Uekawa wrote:
> Anand Kumria <email@example.com> cum veritate scripsit:
> > > I would like to propose ladspa-host and ladspa-plugin as names of virtual packages which
> > >
> > > ladspa-host: application capable of using ladspa-plugins to process audio data
> > > ladspa-plugin: provides plug-in libraries in accordance to the ladspa specification, in /usr/lib/ladspa
> > >
> > I'm clear on what the advantages of these virtual packages are. Could
> > you explain?
> 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.
> Usually a ladspa-aware sound processing program would require a ladspa
> plugin to be available, but it is not essential for its operation. In that
> kind of situation, it would probably Recommends, or Suggests ladspa-plugin.
> Not mentioning anything about it being enhanced by a ladspa-plugin is plainly wrong,
> and declaring depending on a specific ladspa plugin package is clearly wrong.
> 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
> 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.