[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:

> > 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.


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
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: