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