[Bug 527986] Review Request: taoframework - Multimedia bindings for Mono

Sat Oct 17 17:57:00 UTC 2009

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=527986

--- Comment #5 from Christian Krause <chkr at plauener.de>  2009-10-17 13:56:57 EDT ---
Here is the complete review - sorry that it took a little bit longer than
expected:

* rpmlint: OK
rpmlint RPMS/i386/taoframework-* SRPMS/taoframework-2.1.0-1.fc10.src.rpm
SPECS/taoframework.spec
taoframework-cg.i386: W: only-non-binary-in-usr-lib
taoframework-cg.i386: W: no-documentation
taoframework-cg-devel.i386: W: no-documentation
taoframework-devil.i386: W: only-non-binary-in-usr-lib
taoframework-devil.i386: W: no-documentation
taoframework-devil-devel.i386: W: no-documentation
taoframework-doc.i386: W: only-non-binary-in-usr-lib
taoframework-doc.i386: W: no-documentation
taoframework-ffmpeg.i386: W: only-non-binary-in-usr-lib
taoframework-ffmpeg.i386: W: no-documentation
taoframework-ffmpeg-devel.i386: W: no-documentation
taoframework-freeglut.i386: W: only-non-binary-in-usr-lib
taoframework-freeglut.i386: W: no-documentation
taoframework-freeglut-devel.i386: W: no-documentation
taoframework-freetype.i386: W: only-non-binary-in-usr-lib
taoframework-freetype.i386: W: no-documentation
taoframework-freetype-devel.i386: W: no-documentation
taoframework-glfw.i386: W: only-non-binary-in-usr-lib
taoframework-glfw.i386: W: no-documentation
taoframework-glfw-devel.i386: W: no-documentation
taoframework-lua.i386: W: only-non-binary-in-usr-lib
taoframework-lua.i386: W: no-documentation
taoframework-lua-devel.i386: W: no-documentation
taoframework-ode.i386: W: only-non-binary-in-usr-lib
taoframework-ode.i386: W: no-documentation
taoframework-ode-devel.i386: W: no-documentation
taoframework-openal.i386: W: only-non-binary-in-usr-lib
taoframework-openal.i386: W: no-documentation
taoframework-openal-devel.i386: W: no-documentation
taoframework-opengl.i386: W: only-non-binary-in-usr-lib
taoframework-opengl.i386: W: no-documentation
taoframework-opengl-devel.i386: W: no-documentation
taoframework-physfs.i386: W: only-non-binary-in-usr-lib
taoframework-physfs.i386: W: no-documentation
taoframework-physfs-devel.i386: W: no-documentation
taoframework-sdl.i386: W: only-non-binary-in-usr-lib
taoframework-sdl.i386: W: no-documentation
taoframework-sdl-devel.i386: W: no-documentation
26 packages and 1 specfiles checked; 0 errors, 38 warnings.

All of the reported warnings are false-positive:
W: only-non-binary-in-usr-lib: mono assemblies are not recognized as binaries
by rpmlint
W: no-documentation: the API documentation is entirely located in the doc
subpackage

* naming: OK
- name matches upstream
- spec file name matches package name

* sources: OK
- md5sum: a48240aabbb46194a2c347ec262588e2  taoframework-2.1.0.tar.gz
- sources matches upstream
- Source0 tag ok
- spectool -g  works

* binaries in upstream sources: TODO
- the upstream tarball contains a bunch of pre-built binaries (*.exe, *.dll)
- since all delivered content must be built out of the sources, please
delete all binaries in the %prep step just to be on the safe side:

find -name '*.dll' -exec rm -f {} \;
find -name '*.exe' -exec rm -f {} \;

* License: OK
- License in spec file does match the actual license
- MIT license acceptable for Fedora
- one sub-project (Tao.GlBindGen) is licensed under the GPL, but it seems only
to be used to generate the OpenGL C# binding which is done upstream and not
during the build process; the project even builds fine without this
subdirectory
- so for now it doesn't look like a license issue here - however, if any pieces
of this directory are used in an update of taoframework, the license of this
package may be affected

* package containing *.pc files must "Requires: pkgconfig": OK

* spec file written in English and legible: OK

* compilation: TODO
- please check whether the package does support a parallel build, if not please
add a short comment in the %build section
- builds fine in koji: F13, F12, F11

* BuildRequires: OK

* locales handling: OK (n/a)

* ldconfig in %post and %postun: OK (n/a)

* package owns all directories that it creates: OK

* %files section: TODO
In the subpackages you explicitly include the directory with %dir and then all
contained files manually - e.g.:
%dir %{_libdir}/mono/tao-glfw-2.6
%{_libdir}/mono/tao-glfw-2.6/Tao.Glfw.dll
%{_libdir}/mono/tao-glfw-2.6/Tao.Glfw.dll.config

If there is no reason for doing this, I would suggest to use:
%{_libdir}/mono/tao-glfw-2.6

* no files listed twice in %files: OK

* file permissions: OK
- %defattr used
- actual permissions in packages ok

* %clean section: OK

* macro usage: OK

* code vs. content: OK (only code besides some pictures/textures in
examples/Data which are not installed)

* main package (or here: subpackages) should not contain development related
parts: OK

* large documentation into subpackage: OK

* header files in -devel subpackage: OK (n/a)

* static libraries in -static package: OK (n/a)

* *.so link in -devel package: OK (n/a)

* devel package requires base package using fully versioned dependency: OK
- done for all subpackages

* packages must not contain *.la files: OK

* GUI applications must provide *.desktop file: OK (n/a)

* packages must not own files/dirs already owned by other packages: OK

* rm -rf $RPM_BUILD_ROOT at the beginning of %install: OK

* all filenames UTF-8: OK
* functional test: n/a

* debuginfo sub-package: OK (n/a)

* dependencies: TODO
All C# bindings of the taoframework use a quite loose binding to the wrapped
shared objects files by using C#'s dllImport feature together with a mapping to
the actual *.so.* name in the dll.config files - e.g.:
taoframework-opengl uses: libGLU.so.1 and libGL.so.1
This means that if the taoframework's opengl C# binding is used, and the
mono runtime doesn't find the appropriate libGL.so.1, the program will most
likely crash or is aborted due to an exception.

To make use of the dependency resolution algorithms of the package manager, it
would be better if each subpackage would require the appropriate package which
provides the library (if it is available in Fedora's official package
repositories).

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.