On 04/11/2012 11:19 PM, Toshio Kuratomi wrote:
On Wed, Apr 11, 2012 at 09:26:30PM +0200, Brendan Jones wrote:
On 04/11/2012 09:16 PM, Toshio Kuratomi wrote:
So -- I write a plugin and it can be hosted by any number of applications?
Yes - the host application would either use lv2core or slv2 to do so.
Hmmm... okay
So how does this sound as a paraphrase... suil and lv2core are abstractions
for running plugins. They are not abstractions for dependencies. What that
means is that suil and lv2core allow a host application to run any plugin
written for the lv2core framework But it can only do this if the proper
deps are on the system. For instance:
Application foo written using Qt4 and application bar written using gtk2.
If any of qt4, gtk2, or the suil module that allows embedding gtk2 plugins
in a qt4 application are missing, then the bar plugin cannot be loaded into
the suil application.
Again sorry for not being clear: all hosts will require lv2core - this
provides the host with the ability to determine what plugins are
available (determines the plugin path, usually /usr/lib{%suffix}/lv2 or
/home/suer/.lv2, reads the RDF metadata for info) and what
inputs/outputs/control ports they require. It would then use suil to
instantiate it
With these constraints, I think you were (unfortunately :-( right about the
choices. You need all of the siul modules installed since you don't know
what combination of toolkits the particular application and plugin combos
the user is running will need. Filtering the dependencies shouldn't be too
bad for the end user. The plugin and the application will pull in the
correct UI toolkit libraries for the suil module to work. But as the
packager you then have to manually track things that ordinarily are just
a repoquery away.
I'm happy to manage it this way, I guess I will just have to mkae it
very clear in the spec file for future maintainers.
You might be able to use BuildRequires with a specific version to help alert
you to problems and that's not a proactive approach.
Good idea - in fact upstream recommend this and version suil accordingly
(i.e. it is anticipated that multiple versions of suil may be installed,
as this is suil-0 we've just used the package name 'suil' until now, we
could use BuildRequires to further restrict it to the release)
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
