Bug 1311953 - liblas packaging errors
liblas packaging errors
Product: Fedora
Classification: Fedora
Component: liblas (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Devrim Gündüz
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2016-02-25 06:39 EST by Sjoerd Mullender
Modified: 2016-03-15 17:27 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-03-15 17:27:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
liblas.spec (4.40 KB, text/plain)
2016-03-08 06:10 EST, Thomas Kreuzer
no flags Details
liblas.spec (4.05 KB, text/plain)
2016-03-10 07:53 EST, Thomas Kreuzer
no flags Details
liblas.spec (4.05 KB, text/plain)
2016-03-15 07:50 EDT, Thomas Kreuzer
no flags Details

  None (edit)
Description Sjoerd Mullender 2016-02-25 06:39:34 EST
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):


How reproducible:

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 03:35:56 EST
Refer to https://bugzilla.redhat.com/show_bug.cgi?id=1300860
Comment 2 Thomas Kreuzer 2016-03-08 06:10 EST
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??
Comment 3 Thomas Kreuzer 2016-03-10 07:53 EST
Created attachment 1134886 [details]

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 07:50 EDT
Created attachment 1136561 [details]

The license was in the wrong sub-package.
Comment 5 Devrim Gündüz 2016-03-15 17:27:23 EDT
Should be done now. Closing.

Thanks for the patch!

Note You need to log in before you can comment on or make changes to this bug.