Spec URL: http://eh3.com/libLAS.spec SRPM URL: http://eh3.com/libLAS-1.6.0-6.fc14.src.rpm Description: Library and tools for the LAS LiDAR format
The SRPM builds in mock for Fedora-devel and Fedora-14.
MUSTFIX: * /usr/bin/liblas-config is not multilib ready. This script contains hard-coded references to architecture-specific paths => the *-devel.i686 package and the *-devel.x86_64 package can not be installed in parallel. One common work-around to such issues is replacing such *-config scripts by pkg-config files and reimplementing the *-config script as a wrapper around pkg-config. * /usr/bin/liblas-config is broken: e.g.: a) /usr/bin/liblas-config --libs -L/usr/lib -llas -llas_c -L/usr/lib64 optimized;/usr/lib64/libboost_program_options-mt.so;debug;/usr/lib64/libboost_program_options-mt.so /usr/lib64/libgeotiff.so /usr/lib64/libtiff.so /usr/lib64/libxml2.so Note: + -L/usr/lib (on x86_64). + optimized;...;debug;... b) /usr/bin/liblas-config --cflags -I/usr/include /usr/bin/liblas-config --includes -I/usr/include -I/usr/include/libgeotiff -I/usr/include -I/usr/include/libxml2 Using -I/usr/include disturbs the system include path and is never right. c) /usr/bin/liblas-config --cxxflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC -pedantic -ansi -Wall -Wpointer-arith -Wcast-align -Wcast-qual -Wfloat-equal -Wredundant-decls -Wno-long-long -std=c++98
Hi Ralf, thank you for the very quick and helpful feedback! Here's an updated SRPM: http://eh3.com/libLAS-1.6.0-7.fc14.src.rpm which does a better job of using the project-defined lib install directory (fixes the one rpmlint error) and, as an interim measure, removes the non-multilib-compliant /usr/bin/liblas-config from the RPMs. I recently got libLAS commit permission so, pending approval by the project team, I'll add some CMake templates which create and install multilib-compliant %{_libdir}/liblas.pc files as you describe above. And if my bash skills aren't too pathetic I'll also write a new liblas-config which, as you suggest, wraps pkg-config. Would you be willing to approve the above version?
A few things I noticed: The verbose flag for make is not necessary, because CMAKE_VERBOSE_MAKEFILE is already set to "on", when you're using %cmake. See http://www.vtk.org/Wiki/CMake_FAQ#Is_there_an_option_to_produce_more_.27verbose.27_compiling.3F and rpm -E %cmake Please give a rationale in the spec why you're deleting $RPMBUILD/usr/share. The chmod seems unnecessary, since all files in $RPMBUILD/usr/bin are already 755. I think there are some tests and Python bindings as well, is that correct?
Hi Ralf & Volker, An update is available here: http://eh3.com/libLAS.spec http://eh3.com/libLAS-1.6.0-10.fc14.src.rpm and it addresses most of the above comments. The pkgconfig bits are not yet sorted out but I'll try to have an update soon. Aside from the pkgconfig bits, do you spot any blockers?
Here's the promised update: http://eh3.com/libLAS-1.6.0-13.fc14.src.rpm It addresses all the following: 0) improved the pkgconfig (multi-lib) situation -- checked into upstream 1) redundant make-verbose flag removed 2) rationale added for $RPMBUILD/usr/share 3) description of %check section added 4) chmod of $RPMBUILD/usr/bin removed and there are a couple of to-do items: + enable -DWITH_GDAL:BOOL=ON as soon as the GDAL 1.8.x dependency is available and then add the necessary GDAL libs to pkgconfig + package the python bindings -- I will very likely need help with the python packaging or perhaps someone else could handle it -- is anyone interested? And thanks again for taking a look!
Further remarks: MUSTFIXES: * The *.pc is broken: ... libdir=/usr//usr/lib64 ... A detail, I am not sure about how pkgconfig will handle it, is the version number: Version: 1.6.0b4 * AFAICT, several "Requires:" are missing from *-devel. E.g. libstdc++-devel (package uses libstdc++ headers) * Some of the headers contain questionable defines: # grep -R HAVE_ usr/include/* usr/include/liblas/transform.hpp:#ifdef HAVE_GDAL usr/include/liblas/transform.hpp:#ifdef HAVE_GDAL usr/include/liblas/transform.hpp:#ifdef HAVE_GDAL usr/include/liblas/detail/reader/zipreader.hpp:#ifdef HAVE_LASZIP usr/include/liblas/detail/reader/zipreader.hpp:#endif // HAVE_LASZIP usr/include/liblas/detail/zippoint.hpp:#ifdef HAVE_LASZIP usr/include/liblas/detail/zippoint.hpp:#endif // HAVE_LASZIP usr/include/liblas/detail/writer/zipwriter.hpp:#ifdef HAVE_LASZIP usr/include/liblas/detail/writer/zipwriter.hpp:#endif // HAVE_LASZIP - These defines collide with autoconf defines. A proper way to fix this to append such defines with a package specific prefix (e.g. _LIBLAS ...) and to let the package generate a header file providing these defines + to let all files using these defines include it. - liblas need to defined/undefine these defines. Otherwise applications using this library are at risk of using a different API/ABI than the library. Though this occasionally may make sense, I doubt this is intentional. SHOULD/CONSIDER: * Finally, the tarball name being used is causing me headaches, but I am not familiar with mercurial and don't know off-head what the FPG says.
I see that libLAS 1.6.0 has been released. Are you planning to update the submission soon?
Ed, any update?
Ed, are you still interested in maintaining this package?
I guess this review is stalled. Ed, if you are still interested, please respond! Otherwise I'll close this bug as described in http://fedoraproject.org/wiki/Policy_for_stalled_package_reviews Feel free to re-open it any time though.