13 Sep
2007
13 Sep
'07
1:37 p.m.
2007/9/13, Lars Luthman <lars.luthman(a)gmail.com>om>:
On Thu, 2007-09-13 at 14:41 +0100, Steve Harris
wrote:
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
On 13 Sep 2007, at 14:28, elthariel wrote:
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).
2007/9/13, Stefano D'Angelo <zanga.mail(a)gmail.com>om>:
2007/9/13, Benjamin Bruheim <grolgh(a)gmail.com>om>:
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. 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 :/