That is the wrong SRPM or something.

It seems like Brendan provided the SRPM file for sord instead of suil. As the title says it is suil, I believe the following links should be the appropriate ones.
SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-1.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec

Apologies, thanks.

Using the current F16 RPMs from Koji:

Suil Configuration 
Checking for header lv2/lv2plug.in/ns/extensions/ui/ui.h : not found 
The configuration failed

I'm not sure what dependencies you've installed, but this is currently building in rawhide (I believe lv2core-6.0-2 could be the problem)

http://koji.fedoraproject.org/koji/taskinfo?taskID=3726522

lv2core will be updated in f16 shortly

lv2-ui-2.4-4.fc16.x86_64
lv2-ui-devel-2.4-4.fc16.x86_64
lv2core-4.0-3.fc16.x86_64
lv2core-devel-4.0-3.fc16.x86_64

Thanks - added BR lv2core-devel >= 6.0


SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-2.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec

> %files devel
> %{_libdir}/lib%{name}*.so
> %{_libdir}/suil-*/libsuil_gtk2_in_qt4.so
> %{_libdir}/suil-*/libsuil_qt4_in_gtk2.so
> %{_libdir}/pkgconfig/%{name}*.pc
> %{_includedir}/%{name}*/
> ...

Please review  http://fedoraproject.org/wiki/Packaging:UnownedDirectories  as there are several unowned directories in this %files list.

> %files devel
> ...
> %{_libdir}/suil-*/libsuil_gtk2_in_qt4.so
> %{_libdir}/suil-*/libsuil_qt4_in_gtk2.so

Highly dubious to put these into the -devel package. Please prove that these are not dynamically loaded plugins/modules.

(In reply to comment #8)
> > %files devel
> > %{_libdir}/lib%{name}*.so
> > %{_libdir}/suil-*/libsuil_gtk2_in_qt4.so
> > %{_libdir}/suil-*/libsuil_qt4_in_gtk2.so
> > %{_libdir}/pkgconfig/%{name}*.pc
> > %{_includedir}/%{name}*/
> > ...
> 
> Please review  http://fedoraproject.org/wiki/Packaging:UnownedDirectories  as
> there are several unowned directories in this %files list.
> 
> > %files devel
> > ...
> > %{_libdir}/suil-*/libsuil_gtk2_in_qt4.so
> > %{_libdir}/suil-*/libsuil_qt4_in_gtk2.so
> 
> Highly dubious to put these into the -devel package. Please prove that these
> are not dynamically loaded plugins/modules.
Quite right, they're the point of the package after all :)

SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-3.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec

Please remove the version constraints for qt-devel and gtk2-devel. qt-devel will always be newer than 4.0; analogue gtk2.

The author expresses a few specific wishes in PACKAGING. What do you think about them? Do they make sense for Fedora?

Especially having sub-packages for the different toolkits sounds appealing to me. Why would you drag in Qt or GTK if you don't need it? But as far as I can see, both libraries are linked to both toolkits at the moment.

The wish for major version in package names makes sense, given the name of the .so and when I look at where the header file goes:

/usr/include/suil-0/suil/suil.h

Please make {_mandir}/man3/%{name}.3.gz {_mandir}/man3/%{name}.3* in case the compression method changes.

Parts of the build don't use the optflags.

" * Debuggable build                                      : False"

... and rpmlint's ...

  suil-debuginfo.x86_64: E: debuginfo-without-sources

... indicate something is wrong.

(In reply to comment #10)
> Please remove the version constraints for qt-devel and gtk2-devel. qt-devel
> will always be newer than 4.0; analogue gtk2.

Fair enough.

> 
> The author expresses a few specific wishes in PACKAGING. What do you think
> about them? Do they make sense for Fedora?
> 
> Especially having sub-packages for the different toolkits sounds appealing to
> me. Why would you drag in Qt or GTK if you don't need it? But as far as I can
> see, both libraries are linked to both toolkits at the moment.

They are build requirements only. The whole point of the package is to enable linking plugins dynamically at runtime regardless of which toolkit they use. 

> 
> The wish for major version in package names makes sense, given the name of the
> .so and when I look at where the header file goes:
> 
> /usr/include/suil-0/suil/suil.h
> 
> Please make {_mandir}/man3/%{name}.3.gz {_mandir}/man3/%{name}.3* in case the
> compression method changes.

OK

> 
> Parts of the build don't use the optflags.
> 
> " * Debuggable build                                      : False"
> 
> ... and rpmlint's ...
> 
>   suil-debuginfo.x86_64: E: debuginfo-without-sources
> 
> ... indicate something is wrong.

OK, new SRPM imminent

(In reply to comment #10)
> The author expresses a few specific wishes in PACKAGING. What do you think
> about them? Do they make sense for Fedora?

You are quite right. Quoted from PACKAGING
"
The purpose of Suil is to abstract plugin UI toolkits away from host code.  To
achieve this, Suil performs its magic by dynamically loading modules for each
toolkit.  The main Suil library does NOT depend on any toolkit libraries, and
thus neither should your package.  Please package the individual modules
(e.g. libsuil_gtk2_in_qt4.so) as separate packages, which themselves depend on
the involved toolkits.  These packages should also be versioned as described
above to support parallel installation.
"

So, my question is should I provide suil-qt-devel and suil-gtk-devel subpackages from this?

I'm under the impression, something went wrong:

rpm -qp --requires suil-0.4.4-3.fc16.x86_64.rpm 
/sbin/ldconfig  
/sbin/ldconfig  
libQtCore.so.4()(64bit)  
libQtGui.so.4()(64bit)  
libatk-1.0.so.0()(64bit)  
libc.so.6()(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.3.4)(64bit)  
libcairo.so.2()(64bit)  
libdl.so.2()(64bit)  
libdl.so.2(GLIBC_2.2.5)(64bit)  
libfontconfig.so.1()(64bit)  
libfreetype.so.6()(64bit)  
libgcc_s.so.1()(64bit)  
libgcc_s.so.1(GCC_3.0)(64bit)  
libgdk-x11-2.0.so.0()(64bit)  
libgdk_pixbuf-2.0.so.0()(64bit)  
libgio-2.0.so.0()(64bit)  
libglib-2.0.so.0()(64bit)  
libgmodule-2.0.so.0()(64bit)  
libgobject-2.0.so.0()(64bit)  
libgthread-2.0.so.0()(64bit)  
libgtk-x11-2.0.so.0()(64bit)  
libm.so.6()(64bit)  
libpango-1.0.so.0()(64bit)  
libpangocairo-1.0.so.0()(64bit)  
libpangoft2-1.0.so.0()(64bit)  
libpthread.so.0()(64bit)  
librt.so.1()(64bit)  
libstdc++.so.6()(64bit)  
libstdc++.so.6(CXXABI_1.3)(64bit)  
libstdc++.so.6(GLIBCXX_3.4)(64bit)  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1


[ 9/11] cxxshlib: build/src/gtk2_in_qt4.cpp.2.o -> build/libsuil_gtk2_in_qt4.so
23:57:11 runner ['/usr/lib64/ccache/g++', 'src/gtk2_in_qt4.cpp.2.o', '-o', '/media/speicher1/makerpm/rpmbuild/BUILD/suil-0.4.4/build/libsuil_gtk2_in_qt4.so', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lgtk-x11-2.0', '-lgdk-x11-2.0', '-latk-1.0', '-lgio-2.0', '-lpangoft2-1.0', '-lpangocairo-1.0', '-lgdk_pixbuf-2.0', '-lcairo', '-lpango-1.0', '-lfreetype', '-lfontconfig', '-lgobject-2.0', '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lglib-2.0', '-lQtGui', '-lQtCore', '-shared', '-pthread', '-pthread', '-pthread', '-pthread']
[10/11] cxxshlib: build/src/qt4_in_gtk2.cpp.3.o -> build/libsuil_qt4_in_gtk2.so
23:57:11 runner ['/usr/lib64/ccache/g++', 'src/qt4_in_gtk2.cpp.3.o', '-o', '/media/speicher1/makerpm/rpmbuild/BUILD/suil-0.4.4/build/libsuil_qt4_in_gtk2.so', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lgtk-x11-2.0', '-lgdk-x11-2.0', '-latk-1.0', '-lgio-2.0', '-lpangoft2-1.0', '-lpangocairo-1.0', '-lgdk_pixbuf-2.0', '-lcairo', '-lpango-1.0', '-lfreetype', '-lfontconfig', '-lgobject-2.0', '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lglib-2.0', '-lQtGui', '-lQtCore', '-shared', '-pthread', '-pthread', '-pthread', '-pthread']

One devel package should be fine. What would you put in a second devel package?

Apologies (long day here), I need to create two binary packages (one for each .so) ?

No problem!

Yes. Create a suil-gtk and a suil-qt. Both require suil. Common files go to suil.

I can split the packages as you suggest but both binaries still link both toolkits as you've shown. What do you suggest here?

(In reply to comment #13)
> [ 9/11] cxxshlib: build/src/gtk2_in_qt4.cpp.2.o -> build/libsuil_gtk2_in_qt4.so
> 23:57:11 runner ['/usr/lib64/ccache/g++', 'src/gtk2_in_qt4.cpp.2.o', '-o',
> '/media/speicher1/makerpm/rpmbuild/BUILD/suil-0.4.4/build/libsuil_gtk2_in_qt4.so',
> '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lgtk-x11-2.0', '-lgdk-x11-2.0', '-latk-1.0',
> '-lgio-2.0', '-lpangoft2-1.0', '-lpangocairo-1.0', '-lgdk_pixbuf-2.0',
> '-lcairo', '-lpango-1.0', '-lfreetype', '-lfontconfig', '-lgobject-2.0',
> '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lglib-2.0', '-lQtGui', '-lQtCore',
> '-shared', '-pthread', '-pthread', '-pthread', '-pthread']
> [10/11] cxxshlib: build/src/qt4_in_gtk2.cpp.3.o -> build/libsuil_qt4_in_gtk2.so
> 23:57:11 runner ['/usr/lib64/ccache/g++', 'src/qt4_in_gtk2.cpp.3.o', '-o',
> '/media/speicher1/makerpm/rpmbuild/BUILD/suil-0.4.4/build/libsuil_qt4_in_gtk2.so',
> '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lgtk-x11-2.0', '-lgdk-x11-2.0', '-latk-1.0',
> '-lgio-2.0', '-lpangoft2-1.0', '-lpangocairo-1.0', '-lgdk_pixbuf-2.0',
> '-lcairo', '-lpango-1.0', '-lfreetype', '-lfontconfig', '-lgobject-2.0',
> '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lglib-2.0', '-lQtGui', '-lQtCore',
> '-shared', '-pthread', '-pthread', '-pthread', '-pthread']

OK, I think we can ignore the last comment. I have rebuilt qtractor with suil and it seems to link as expected with the split packages.

SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-4.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec

While the gtk sub-package seems fine from a dependency point of view, the qt sub-package still requires libgtk-x11-2.0.so.0, which is provided by gtk2. Installing the qt sub-package would therefore drag in gtk, which is not desireable.

I recommend to write %{name}.3* instead of %{name}.3.gz, as the type of compression could change in the future.

You're not using the name macro consistently.

The first couple of files are still not compiled with optflags.

OK, updated the man, macros and optflags (good catch).

Can't do anything about about the gtk dependencies in the qt lib - have a look at the source. 

SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-5.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec

Link is dead.

Apologies, here 'tis.

SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-5.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec

You're right and this claim is not precise:

"Suil currently supports Gtk 2 and Qt 4, i.e. with Suil a Gtk program can embed a Qt plugin UI without depending on Qt, and a Qt program can embed a Gtk plugin UI without depending on Gtk." -- http://drobilla.net/software/suil/

Your description explains it better, in my opinion.

My comments:
* The license tag should be MIT:
   https://fedoraproject.org/wiki/Licensing/MIT#Old_Style_with_legal_disclaimer_2

* The description of the gtk subpackage is the same as the qt package. Copy/paste error?
At this point I want to question the rationale of splitting the package into subpackages. Why do we need this? If we really need this please make the descriptions more descriptive, as
   "This package contains the Qt library for %{name}."
is ambiguous for such a package.

! I need to make a note that in Fedora the Qt4 packages usually use
   BuildRequires:  qt4-devel

- The rpmlints
   suil-gtk.x86_64: W: no-documentation
   suil-qt.x86_64: W: no-documentation
   suil.x86_64: W: spelling-error %description -l en_US toolkits -> toolkit, tool kits, tool-kits
   suil.x86_64: W: spelling-error %description -l en_US runtime -> run time, run-time, rudiment
can be ignored

(In reply to comment #24)
> My comments:
> * The license tag should be MIT:
>   
> https://fedoraproject.org/wiki/Licensing/MIT#Old_Style_with_legal_disclaimer_2

OK as the ISC license is an MIT derivative and is word for word the same as your link I will change the license (https://www.isc.org/software/license)
Both are good licenses, this package will report ISC when using licensecheck however.

> 
> * The description of the gtk subpackage is the same as the qt package.
> Copy/paste error?
> At this point I want to question the rationale of splitting the package into
> subpackages. Why do we need this? If we really need this please make the
> descriptions more descriptive, as
>    "This package contains the Qt library for %{name}."
> is ambiguous for such a package.

I'm happy to question this again. If I have this correctly, any host which is build against suil will require both libraries. It won't know at runtime what toolkits a plugin may use until its asked to instantiate it, and the way the package is split at the moment we run the risk of a missing a runtime  dependency. The only advantage I see at the moment is that it would be possible to have a Qt host that only loads Qt plugins but I think that's inviting trouble without having any Gtk libraries (in which case the user decides which suil library they have to install manually - yeuch).
Is that your take? I think we should probably move them back into the main package

> 
> ! I need to make a note that in Fedora the Qt4 packages usually use
>    BuildRequires:  qt4-devel
> 
> - The rpmlints
>    suil-gtk.x86_64: W: no-documentation
>    suil-qt.x86_64: W: no-documentation
>    suil.x86_64: W: spelling-error %description -l en_US toolkits -> toolkit,
> tool kits, tool-kits
>    suil.x86_64: W: spelling-error %description -l en_US runtime -> run time,
> run-time, rudiment
> can be ignored

OK, I've merged the two sub-packages back into the main package and manually removed Gtk and Qt requires from the suil package. These libraries should be required by the plugin and need not be pulled in here.

SRPM:  http://bsjones.fedorapeople.org/lv2/suil-0.4.4-6.fc16.src.rpm
SPEC:  http://bsjones.fedorapeople.org/lv2/suil.spec

Hi Brendan, thanks for the update. Yes I would go with putting everything in one package, but...

(In reply to comment #26)
> OK, I've merged the two sub-packages back into the main package and manually
> removed Gtk and Qt requires from the suil package. These libraries should be
> required by the plugin and need not be pulled in here.

I am not sure that I follow you here. From my understanding, any plugin that uses suil will need both gtk and Qt libraries installed, since the plugin will convert a gtk ui to Qt, or vice versa.

What is the difference between this situation, and a library package X requiring another binary package Y? We don't typically filter out the Y requirement from the library X and expect the application Z to require both X and Y.

Sorry, it should be s/binary/library/ in the previous comment.

Hi Orcan,

I have discussed this with Dave Robillard and some of the other Fedora devs and after a lengthy discussion this was considered the best way to satisfy the intentions/purpose of the library.

The suil package was designed not to depend on either toolkit. So if we have a Qt host and a Gtk plugin, then the Qt dependencies are provided by the host and the Gtk dependencies are provided by the plugin. The host cannot know at runtime what toolkit it maybe required to use to instantiate a plugin and shouldn't be expected to require both.

The filtered requires ensures that only the toolkit of the host is pulled in.  This may be advantageous where it is not desirable to pull in libraries unnecessarily.

Thanks for the explanation. Do you have any links for the discussions?

Please correct me if I am wrong: If gtk and Qt are the only supported toolkits by suil, then the plugin will drag in the Qt and the host will drag in gtk, or vice versa. Since both gtk and Qt will be dragged in in either case, it does not matter if the toolkit dependencies of suil are filtered out or not. However the story changes if suil supports more than these 2 toolkits (which is not the case for the time being). 

On the other hand, my biggest concern was not the above scenario exactly. It is not uncommon that Qt updates come  with ABI incompatibility. In such circumstances, the Fedora-KDE SIG works well-coordinated to rebuild all Qt dependant packages. If you filter out the Qt dependency from suil, they will not know about the existence of it. The suil maintainer (that will be you until you give it up) will need to follow all the ABI related changes in the underlying toolkit Qt and has to coordinate manually with the Qt updates at all times.
A similar argument applies for gtk rebuilds (although admittedly I don't have much experinence with gtk), or any other toolkit that will be supported by suil in the future. 

Are you sure do you want to walk that road? Shall we ask this in the Fedora-packaging list perhaps? What is so bad about dragging in the toolkits (seriously)?

(In reply to comment #30)
> On the other hand, my biggest concern was not the above scenario exactly. It is
> not uncommon that Qt updates come  with ABI incompatibility. In such
> circumstances, the Fedora-KDE SIG works well-coordinated to rebuild all Qt
> dependant packages. If you filter out the Qt dependency from suil, they will
> not know about the existence of it. The suil maintainer (that will be you until
> you give it up) will need to follow all the ABI related changes in the
> underlying toolkit Qt and has to coordinate manually with the Qt updates at all
> times.
> A similar argument applies for gtk rebuilds (although admittedly I don't have
> much experinence with gtk), or any other toolkit that will be supported by suil
> in the future.

Sure, understand that this is a real concern.
 
> 
> Are you sure do you want to walk that road? Shall we ask this in the
> Fedora-packaging list perhaps? What is so bad about dragging in the toolkits
> (seriously)?

Attached (part of) a discussion on IRC with #lv2. 

Sure, I understand what you are saying. Whilst both toolkits are *likely* to be present anyway I can also envision a scenario whereby this may not be the case (e.g. a remix on an embedded device)

I could package without the requires, make a note of it in the spec file and revisit again if presented with a requirement to remove the unnecessary dependencies. Although it does irk me to go against upstream's recommendations

Created attachment 576375 [details]
#lv2 IRC discussion excerpt

I raised this on the packaging list as asked. Comments from Toshio only at this stage, confirming my approach.

http://lists.fedoraproject.org/pipermail/packaging/2012-April/008276.html

Alright then, we do not have any other issues, thus we can approve the package.

But please consider the versioned BR suggestion of Toshio, also please make a note in the specfile for tracking the changes in the underlying toolkits.

---------------------------------------
This package (suil) is APPROVED by oget
---------------------------------------

Thanks for the review Orcan. Will do.

New Package SCM Request
=======================
Package Name: suil
Short Description: A lightweight C library for instantiating LV2 plugin UIs 
Owners: bsjones
Branches: f15 f16 f17
InitialCC:

Git done (by process-git-requests).

suil-0.4.4-8.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/suil-0.4.4-8.fc16

suil-0.4.4-8.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/suil-0.4.4-8.fc17

suil-0.4.4-8.fc17 has been pushed to the Fedora 17 testing repository.

suil-0.4.4-8.fc16 has been pushed to the Fedora 16 stable repository.

suil-0.4.4-8.fc17 has been pushed to the Fedora 17 stable repository.