FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 04-11-2012, 03:00 PM
Brendan Jones
 
Default Filtering requires

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


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?

thanks,

Brendan


[1] http://drobilla.net/software/suil/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=783825



--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-11-2012, 04:00 PM
Toshio Kuratomi
 
Default Filtering requires

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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-11-2012, 04:45 PM
Brendan Jones
 
Default Filtering requires

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

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-11-2012, 06:27 PM
Toshio Kuratomi
 
Default Filtering requires

On Wed, Apr 11, 2012 at 06:45:15PM +0200, Brendan Jones wrote:
> On 04/11/2012 06:00 PM, Toshio Kuratomi wrote:
> >
> >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.
>
So.. what is a host and what is lv2core?

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-11-2012, 07:04 PM
Brendan Jones
 
Default Filtering requires

On 04/11/2012 08:27 PM, Toshio Kuratomi wrote:

On Wed, Apr 11, 2012 at 06:45:15PM +0200, Brendan Jones wrote:

On 04/11/2012 06:00 PM, Toshio Kuratomi wrote:


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.


So.. what is a host and what is lv2core?



A host is any application that instantiates an LV2 plugin - e.g. best
known examples are apps like qtractor or ardour. Although there are
others like lv2rack (which doesn't use suil). Eventually I think LV2
will be a drop in replacement for LADSPA plugins, but its not quite
there yet.

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-11-2012, 07:16 PM
Toshio Kuratomi
 
Default Filtering requires

On Wed, Apr 11, 2012 at 09:04:11PM +0200, Brendan Jones wrote:
> On 04/11/2012 08:27 PM, Toshio Kuratomi wrote:
> >On Wed, Apr 11, 2012 at 06:45:15PM +0200, Brendan Jones wrote:
> >>On 04/11/2012 06:00 PM, Toshio Kuratomi wrote:
> >>>
> >>>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.
> >>
> >So.. what is a host and what is lv2core?
> >
>
> A host is any application that instantiates an LV2 plugin - e.g. best
> known examples are apps like qtractor or ardour. Although there are
> others like lv2rack (which doesn't use suil). Eventually I think LV2
> will be a drop in replacement for LADSPA plugins, but its not quite
> there yet.
>
So -- I write a plugin and it can be hosted by any number of applications?

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-11-2012, 07:26 PM
Brendan Jones
 
Default Filtering requires

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.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-11-2012, 09:01 PM
Brendan Jones
 
Default Filtering requires

On 04/11/2012 09:26 PM, 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.

Seeing as suil is deprecating slv2 - suil to do so
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-11-2012, 09:19 PM
Toshio Kuratomi
 
Default Filtering requires

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.

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.

You might be able to use BuildRequires with a specific version to help alert
you to problems and that's not a proactive approach.

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-12-2012, 01:33 PM
Brendan Jones
 
Default Filtering requires

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 09:00 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org