A common plugin repository (WAS:Re: [LAD] ladspa qa?)

[Lars Luthman]

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


--ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20070913/325a076b/attachment.pgp>