[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 rc040203 at 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.