Red Hat Bugzilla – Bug 1311953
liblas packaging errors
Last modified: 2016-03-15 17:27:23 EDT
Description of problem:
There are a bunch of packaging problems with liblas and its subpackages.
On Fedora 22, liblas-libs does not require liblas, even though it contains symlinks to files that are in liblas (/usr/lib64/libas.so and /usr/lib64/liblas_c.so).
On both Fedora 22 and 23, liblas-devel does not depend on gdal-devel and libgeotiff-devel, even though those packages are required for successfully building something with liblas.
The liblas-config program produces incorrect compiler options:
liblas-config --libs produces -L/usr/lib on a 64-bit system (should be -L/usr/lib64) and absolute path names for several libraries (instead of -l options).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.dnf install liblas-devel
The first command doesn't install gdal-devel or libgeotiff-devel, and on Fedora 22, also not liblas.
The second command shows that /usr/include/gdal and /usr/include/libgeotiff are used, and thus that gdal-devel and libgeotiff-devel are required.
The third command shows the -L/usr/lib flag and the absolute path names of libraries.
The first command should also install gdal-devel, libgeotiff-devel and liblas.
The third command should not include -L/usr/lib on a 64-bit architecture.
Also see bug 1300860.
Refer to https://bugzilla.redhat.com/show_bug.cgi?id=1300860
Created attachment 1134095 [details]
The old SPEC file had wrong file ownerships (thus 1. shouldn't need to install liblas anymore), I corrected that.
I also gave the *-devel requirements to liblas-devel.
As of https://bugzilla.redhat.com/show_bug.cgi?id=1300860 I also corrected the linking, if this is actually the correct way, since liblas works with "DLL" functions to determine linkage at runtime, maybe it actually needs the full path??
Created attachment 1134886 [details]
I did some more modifications to the SPEC file. Some are just cosmetic in nature, and might be ignored, if they are not liked (descriptions and summaries).
However, I did change the packaging scheme:
liblas - versioned libraries
liblas-devel - unversioned libraries, header files, liblas-config, and cmake stuff
liblas-tools - binary libLAS utility applications
this scheme follows other library packages, like libtiff, because having a liblas-libs package is kind of a pleonasm.
Created attachment 1136561 [details]
The license was in the wrong sub-package.
Should be done now. Closing.
Thanks for the patch!