On Tue, May 22, 2001 at 12:34:48AM +0900, Junichi Uekawa wrote: > Anand Kumria <[EMAIL PROTECTED]> 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 provide that. > > 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. Cheers, Anand
