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@xxxxxxxxxx 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review