Bug#96873: virtual-package names, ladspa-host and ladspa-plugin
Anand Kumria <akumria@debian.org> 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.
--
dancer@debian.org 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------
Reply to: