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

[Stefano D'Angelo]

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