[Fedora-packaging] Filtering requires

[Toshio Kuratomi]

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 :-)

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.

> 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).
* 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).
* A plugin for the application will:
** Always depend on the main suil package.
** Also have a dependency on the toolkit library that it depends on
  (automatically extracted by rpm if the application was linked correctly).
** 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.

So two hypothetical examples:
Application foo which uses Qt4 and plugin bar that uses Qt4:

$ rpm -q --requires foo
[..]
libsuil.so.0
libQtCore.so.4
libQtGUI.so.4
[..]

$ rpm -q --requires bar
[..]
libsuil.so.0
libQtCore.so.4
libQtGUI.so.4
[..]

Application foo which uses Qt4 and plugin bar that uses gtk2:

$ rpm -q --requires foo
[..]
libsuil.so.0
libQtCore.so.4
libQtGUI.so.4
[..]

$ rpm -q --requires bar
[..]
libsuil.so.0
libgtk-x11-2.0.so.0
suil-gtk2-in-qt4
[..]

This dependency is explicitly specified in the bar spec file as:
  Requires: suil-gtk2-in-qt4

> [2] https://bugzilla.redhat.com/show_bug.cgi?id=783825

In the Review Request someone said they weren't sure why there needed to be
subpackages for the embedders if all the embedders required the same
libraries.  The reason is that the matrix should also include the case where
there's no cross-toolkit embedding occurring (example: application uses Qt4
and plugin also uses Qt4)

You could simplify somewhat by placing plugins that both require the same
toolkits together.  So hypothetically, if suil also supported wxwidgets you
could have:

* suil
** main suil package with libsuil.so.0

* suil-gtk2-qt4
** libsuil_qt4_in_gtk2.so
** libsuil_gtk2_in_qt4.so

* suil-gtk2-wx2
** libsuil_gtk2_in_wx2.so
** libsuil_wx_in_gtk2.so

* suil-qt4-wx2
** libsuil_qt4_in_wx2.so
** libsuil_wx_in_qt4.so

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20120411/16da958e/attachment.sig>