A common plugin repository (WAS:Re: [LAD] ladspa qa?)
Stefano D'Angelo
zanga.mail at gmail.com
Thu Sep 13 15:37:42 UTC 2007
2007/9/13, Lars Luthman <lars.luthman at gmail.com>:
> On Thu, 2007-09-13 at 14:41 +0100, Steve Harris wrote:
> > On 13 Sep 2007, at 14:28, elthariel wrote:
> >
> > >
> > > 2007/9/13, Stefano D'Angelo <zanga.mail at gmail.com>:
> > > 2007/9/13, Benjamin Bruheim <grolgh at gmail.com>:
> > > > I am working on a site zzub.org which might feature binary
> > > downloads
> > > > of Ladspa plugins for windows, and on linux once it gets
> > > into a
> > > > fashionable state. But I would love to learn what
> > > meta-data would be
> > > > required for each binary version on the server so that a
> > > client would
> > > > be able to determine what version would work on your
> > > OS/Distro.
> > >
> > > I'd say package format (.rpm, .deb, etc), OS distribution
> > > (Ubuntu,
> > > OpenSUSE, etc.), CPU architecture (ix86, x86_64, etc.) and
> > > maybe
> > > binary format (ELF, .dll, etc.). I guess a description
> > > wouldn't hurt
> > > too.
> > > Personally, I'd like to see also some categorization stuff,
> > > user
> > > comments, votes, demos and so on.
> > >
> > > This is planned, i'm currently working on it.
> > > I think the packaging problem should be handled by the library who
> > > access the repository through a webservice. I think binary form,
> > > event with its disavantadge is easier for the musician :/
> >
> >
> > It's not quite that simple ofcourse - most plugins now consist of
> > multiple files (at least a .so and .rdf), plus may have library
> > dependencies. Not that this should stop you.
>
> The easiest thing would probably be to have a library that calls some
> sort of internet service that maps (plugin ID, platform) to a package
> name, for example ("LADSPA:1198", "Debian/Etch/amd64") -> "swh-plugins".
> Then the package swh-plugins can be installed, automatically if desired,
> using the normal distribution tools (e.g. 'aptitude install swh-plugins'
> in this case).
Yes, it's probably the easiest... but IMHO I think that it would be
much better to "directly" access the package manager when possible
(using libapt-pkg and similar).
This would probably give much more sensitive information to the
applcation using that library (for example, think about a GUI dealing
this issue running an unkown package management tool... the best you
can do is opening a terminal window showing the package manager output
and catching its return value).
Anyway, it is probably difficult and/or time consuming to do it this
way... I, for myself, would be happy in either case.
Stefano
More information about the Linux-audio-dev
mailing list