[Fedora-packaging] Filtering requires

[Brendan Jones]

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)