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.
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.
regards,
junichi
--
[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------
