[Bug 190991] Review Request: libpar2

[bugzilla at redhat.com]

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

Summary: Review Request: libpar2


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





------- Additional Comments From laurent.rineau__fc_extra at normalesup.org  2006-05-08 10:18 EST -------
Update:
Spec URL: http://www.di.ens.fr/~rineau/Fedora/libpar2.spec
SRPM URL: http://www.di.ens.fr/~rineau/Fedora/libpar2-0.2-2.src.rpm

Thank you for your comments, Ralf.

(In reply to comment #2)
> 1. Minor issues:
> 
> 1.1
> # rpmlint *RPMS/libpar*.rpm
> E: libpar2-debuginfo script-without-shellbang

I fixed these one. I forgot to apply rpmlint to the debuginfo package.

> E: libpar2-devel only-non-binary-in-usr-lib

I saw this one. I thought it is related to %{_libdir}/libpar2/include/config.h 
See my answer to your point 3.

> Most of these probably are caused by bogus permissions on source files.
> 
> 1.2 Empty directory
> /usr/lib/libpar2
> Is this package supposed to take plugins, there?

It should includes a subdirectory include/, with config.h in it. See point 3.

> 2. Major:
> This package's configuration (configure.ac/Makefile.am) is bugged:
> - configure.ac uses PKG_CHECK_MODULES(..sigc++..) but doesn't propagate the
> results to Makefile.am. Instead the Makefile explicitly links against 
-lstdc++.
> This violates g++'s working principles. Linking against -lstdc++ is a g++
> internal detail.

This is an upstream bug. I am not an automake guru (not yet). I added a patch 
in the package. It should correct this point. I'll try to make this patch 
accepted by upstream, as soon as somebody confirms that this patch is correct.

> 3. Severe (Blocker):
> The package installs an autoheader (config.h) to a public directory
> (/usr/lib/libpar2/include/config.h). This file's contents will clash with 
other
> package's config headers and is a severe (must fix) design flaw of this 
package.
> A package must not install an autoheader.

I do not understand this point. This file config.h is in a directory owned by 
the package: %{_libdir}/libpar2/include/

If a package cannot install an autoheader (such as config.h), how could 
dependencies access to the compilation options used to build the package?

I have checked that several packages, some in FE, have config.h in 
%{_libdir}/%{name}/include: at least sigc++-2.0, gtkmm-2.4, glib-2.0, and 
gtk-2.0. I thought this was the usual way to process with config.h

Can you confirm that this point is a blocker for this request? As far as I 
understand things, it does not seem too.


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.