[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#96873: virtual-package names, ladspa-host and ladspa-plugin

Anand Kumria <akumria@debian.org> 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.

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
things slightly more difficult to maintain, if such virtual package names did 
not exist.

This is my explanation as to why these virtual package names are required.


dancer@debian.org  http://www.netfort.gr.jp/~dancer
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+ 

Reply to: