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 rc040203(a)freenet.de 2006-05-08 11:12 EST -------
(In reply to comment #3)
> 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?
There is
no general answer to this question, but "somehow" - This is the basic
question package configuration tools want to solve.
The fundamental design flaws with exporting config header are:
* autoheaders generated config.h's contain a snapshot of the build system's
state having been taken at the time the configure script had been run.
This state is by no means connected to a system's state, the package had been
installed on.
* autoheaders contain defines that are reserved to autoconf and will clash with
those autoconf internal defines being used by configure scripts wanting to use
this library. (E.g. /usr/lib/libpar2/include/config.h's PACKAGE_NAME will do so)
* autoheaders reflect a package's internal demands/requirements. These are not
connected to a package "using a package"'s demands.
AFAIS, libpar2 expects packages using it to provide a set of autoconf defines.
This doesn't work.
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
If the files you
are referring to are autoheaders, these packages are also bugged.
libtiff is a well known case having suffered (still suffering?) from this issue.
Can you confirm that this point is a blocker for this request?
Yes, it is.
The sources are suffering from a design flaw which disqualify this
package from FE.
--
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.