Bug 1311953

Summary: liblas packaging errors
Product: [Fedora] Fedora Reporter: Sjoerd Mullender <sjoerd>
Component: liblasAssignee: Devrim Gündüz <devrim>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: devrim, thomas.kreuzer
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-15 21:27:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
liblas.spec
none
liblas.spec
none
liblas.spec none

Description Sjoerd Mullender 2016-02-25 11:39:34 UTC
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):
liblas-1.8.0-3.fc22.x86_64
liblas-devel-1.8.0-3.fc22.x86_64
liblas-libs-1.8.0-3.fc22.x86_64

liblas-1.8.0-7.fc23.x86_64
liblas-devel-1.8.0-7.fc23.x86_64
liblas-libs-1.8.0-7.fc23.x86_64


How reproducible:
100%

Steps to Reproduce:
1.dnf install liblas-devel
2.liblas-config --includes
3.liblas-config --libs

Actual results:
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.

Expected results:
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.

Additional info:
Also see bug 1300860.

Comment 1 Thomas Kreuzer 2016-03-04 08:35:56 UTC
Refer to https://bugzilla.redhat.com/show_bug.cgi?id=1300860

Comment 2 Thomas Kreuzer 2016-03-08 11:10:02 UTC
Created attachment 1134095 [details]
liblas.spec

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??

Comment 3 Thomas Kreuzer 2016-03-10 12:53:48 UTC
Created attachment 1134886 [details]
liblas.spec

Hallo again,

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.

Comment 4 Thomas Kreuzer 2016-03-15 11:50:56 UTC
Created attachment 1136561 [details]
liblas.spec

The license was in the wrong sub-package.

Comment 5 Devrim Gündüz 2016-03-15 21:27:23 UTC
Should be done now. Closing.

Thanks for the patch!