[Fedora-packaging] Filtering requires

[Brendan Jones]

On 04/11/2012 06:00 PM, Toshio Kuratomi wrote:
> On Wed, Apr 11, 2012 at 05:00:36PM +0200, Brendan Jones wrote:
>> Hi all
>>
>> I have a library (suil [1]) currently under review [2] which enables
>> audio software such as qtractor/ardour etc to instantiate LV2 audio
>> plugins. Whilst not part of the LV2 specification, it is being
>> maintained by the authors of LV2 and will obsolete slv2 which is what
>> hosts currently use.
>>
>> An instantiated plugin may use a different UI toolkit than the host
>> and one of purposes of the suil library is to free the host
>> application from unnecessary explicit runtime toolkit dependencies
>> (Qt/Gtk only at this stage).
>>
> I'm going to paraphrase what you said here and what's in the review request
> to be sure I understand :-)

Sorry, its hard too explain concisely without presenting a tome of 
information! Thanks for paraphrasing, few comments below which may clear 
things up (or not :|)

>
> There is a library named suil whose purpose is to allow an application to
> require one UI toolkit and that application's plugins to require a different
> UI toolkit.
>
> The suil library itself has compiled plugins that enable different types of
> embedding (qt4 in gtk2 and gtk2 in qt4 at the moment).  These suil plugins
> need to require two toolkits apiece: the toolkit that is being embedded and
> the toolkit that is being embedded into.

suil is somewhat parallel to the spec - the host could instantiate the 
plugin on its own (using lv2core) if it wanted to. I guess the best way 
is to consider suil a helper library using lv2core which saves the host 
from doing the heavy lifting.

>
>> As it stands RPM automatic requires will pull in requires for both
>> toolkits, so that any Qt host using suil will pull in Gtk and vice
>> versa. Whilst on most systems these will be present anyway it may not
>> always be the case nor desirable (and it kind of defeats what
>> upstream have set out to achieve).
>>
>> I can filter out the toolkit requires in suil which will solve the
>> problem, but it leaves the maintainer (me for now) in a position of
>> manually tracking changes in Qt/Gtk that may require a rebuild of
>> suil.
>>
>> Alternatively I could filter the requires on any hosts that use suil,
>> (only one at this stage but inevitably more), but that again this is
>> cumbersome as more and more hosts come onbooard.
>>
>> The safest course is to leave the automatic requires alone, pull in
>> both toolkits for every host and deal with it differently when/if
>> asked but it doesn't sit *right* with me.
>>
>> Any comments on the best way to handle this?
>>
> Assuming that I understand what suil does, I think this is what things
> should look like:
>
> * Main suil package which contains libsuil.  This does not depend on any
>    toolkits.
> * Subpackages per embedder that are named like this: suil-gtk2-in-qt4
>    and Require the two toolkits that the plugin needs (in this case, gtk2 and
>    qt4).

suil will read the metadata of the plugin bundle, find its location, 
determine what toolkit it requires and employ one of suil-gtk2-in-qt4 or 
suil-qt4-in-gtk2 libraries to work out what it needs to do

> * An application that depends on suil will require the main suil package and
>    separately, the toolkit library that it depends on (automatically
>    extracted by rpm if the application was linked correctly).

Yes, ideally a host application will require suil, and suil only.

> * A plugin for the application will:
> ** Always depend on the main suil package.

Never, no LV2 plugin will ever know about suil.

> ** Also have a dependency on the toolkit library that it depends on
>    (automatically extracted by rpm if the application was linked correctly).

Correct, so we are not touching any of the automatic dependencies of the 
plugin

> ** Additionally, the plugin package needs to know what toolkit the
>     application is using.  If it is different than the toolkit that the
>     plugin is using, the plugin's rpm package will have a manually added
>     dependency on the proper suil subpackage for embedding.

Again, a plugin has no foreknowledge of its host nor any intermediate 
library which may be used to instantiate it.

Whilst filtering the requires solves one problem, it creates another and 
thats tracking abi changes etc against suil. Positive in one sense as 
only suil will ever need rebuilding when this occurs?

thanks for the patience

Brendan