Bugzilla Bug 105760

sci-libs/gdal appears to suffer the RPATH issues in bug #81745.  This shows up
for me as a problem on both versions 1.2.6-r3 and 1.3.0.

Emerge error for 1.2.6-r3;
prepallstrip:
strip: sparc-unknown-linux-gnu-strip --strip-unneeded
   usr/lib/libgdal.so.1.7.0
   usr/lib/python2.4/site-packages/_gdalmodule.so
   usr/bin/ogr2ogr
   usr/bin/ogrinfo
   usr/bin/ogrtindex
   usr/bin/gdalinfo
   usr/bin/gdal_translate
   usr/bin/gdaladdo
   usr/bin/gdalwarp
   usr/bin/gdal_contour
   usr/bin/gdaltindex
making executable: /usr/lib/libgdal.so.1.7.0

QA Notice: the following files contain insecure RUNPATH's
 Please file a bug about this at http://bugs.gentoo.org/
 For more information on this issue, kindly review:
 http://bugs.gentoo.org/81745
/var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/ogr2ogr
/var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/ogrinfo
/var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/ogrtindex
/var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdalinfo
/var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdal_translate
/var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdaladdo
/var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdalwarp
/var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdal_contour
/var/tmp/portage/gdal-1.2.6-r3/image/usr/lib usr/bin/gdaltindex


!!! ERROR: sci-libs/gdal-1.2.6-r3 failed.
!!! Function dyn_install, Line 1044, Exitcode 0
!!! Insecure binaries detected
!!! If you need support, post the topmost build error, NOT this status message.


Emerge error for 1.3.0
prepallstrip:
strip: sparc-unknown-linux-gnu-strip --strip-unneeded
   usr/lib/libgdal.so.1.8.0
   usr/lib/python2.4/site-packages/_gdalmodule.so
   usr/bin/ogr2ogr
   usr/bin/ogrinfo
   usr/bin/ogrtindex
   usr/bin/gdalinfo
   usr/bin/gdal_translate
   usr/bin/gdaladdo
   usr/bin/gdalwarp
   usr/bin/gdal_contour
   usr/bin/gdaltindex
making executable: /usr/lib/libgdal.so.1.8.0

QA Notice: the following files contain insecure RUNPATH's
 Please file a bug about this at http://bugs.gentoo.org/
 For more information on this issue, kindly review:
 http://bugs.gentoo.org/81745
/var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/ogr2ogr
/var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/ogrinfo
/var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/ogrtindex
/var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdalinfo
/var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdal_translate
/var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdaladdo
/var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdalwarp
/var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdal_contour
/var/tmp/portage/gdal-1.3.0/image/usr/lib usr/bin/gdaltindex


!!! ERROR: sci-libs/gdal-1.3.0 failed.
!!! Function dyn_install, Line 1044, Exitcode 0
!!! Insecure binaries detected
!!! If you need support, post the topmost build error, NOT this status message.

Reporter : could you please check that it still happens after the latest Perl
upgrade...

No change here with the new perl (not even sure if gdal uses perl)

Created an attachment (id=69704) [details]
path against gdal ebuilds

TOFIX: both sci-geosciences/grass and sci-libs/gdal depend on each other
As such I haven't tested with use=grass

TODO: test application - I've only done compile and install path tests.
TODO: submit install path fix patch upstream

fyi note: install path patch was generated with
sed -i -e  's/\($(INSTALL.*\)$(INST_/\1$(DESTDIR)$(INST_/g' `find . -name
GNUmakefile`

with:
GDALmake.opt.in
-INST_DATA	=	@datadir@
+INST_DATA	=	@datadir@/gdal

Jason - i think you're right - no perl is used.

Created an attachment (id=69708) [details]
gdal-1.2.6-installpathfix.patch

Created an attachment (id=69709) [details]
gdal-1.3.0-installpathfix.patch

Pulling in herd as the maintainer doesn't seem to respond.

It'll have to wait until after work tomorrow when I can see again...

Updated and patched.

TOFIX: both sci-geosciences/grass and sci-libs/gdal depend on each other 
 
gdal-1.2.5-r1.ebuild could be removed. 
 
for glsa's sake you probably need revision bumps on gdal-1.2.6-r3.ebuild -> 
-r4 and 1.3.0 -> -r1 
 
A little credit to the patch contributor couldn't hurt either. 
 
I'm assuming you pushed a patch upstream. I will if you want me too. 

> TOFIX: both sci-geosciences/grass and sci-libs/gdal depend on each other  
 
http://lists.maptools.org/pipermail/gdal-dev/2005-September/006565.html  
not sure it helps - I tested and it really does seems as though they depend on 
each other. 
 
* bump * cause a solution is needed. 

Yes depenancy resolution is a hard problem. From above URL 
 
"The problem with GRASS and GDAL was solved as part of the 
Debian GIS effort and revolves around building the GDAL 
GRASS driver as a separate package using the plugin API. 
Presumably a similar approach would be advisable for Fedora." 
 
And the next email in the thread: 
http://lists.maptools.org/pipermail/gdal-dev/2005-September/006566.html 
Silke Reimer Silke.Reimer at intevation.de: 
"As I already tried to explain in the thread one year ago this can 
only be solved by packaging the grassgdal-plugin in a seperate 
package. It happens that I will build a new grass package for FC4 
together with this plugin within the next few weeks (hopefully 
already this week)." 
 
I assume this is the thread from a year ago: 
http://lists.maptools.org/pipermail/gdal-dev/2004-August/003877.html 
 
Does debian's package dependancy structure help? 
packages.debian.org search gdal and grass 
 
 

I was thinking something similar last night, ie, it should work okay like so:

Change the grass USE flag in gdal to "libgrass" and add an ebuild for libgrass 
(meaning a new ebuild in sci-libs where only the Grass6 libs are installed). 
I haven't worked out the details yet as far as the dependency subset for 
libgrass, but it sounds good after a couple of beers...  :)

It would conflict with the full Grass ebuild, but I think we have the ebuild 
functions to detect it and merge with it (or just make a reverse dep).  I'm 
sure there are people with more portage foo than I have...

Steve: how about splitting grass into grass-lib and grass-main, and make
grass-main and gdal depend on grass-lib ? If you trim grass-main sufficiently
there shouldn't be a conflict with grass-lib... and the "grass" USE flag would
just be kept the same.

disclaimer: I don't know the apps in question at all.
disclaimer2: "grass-main" should probably just be called "grass".

Any progress on this one? 

Removed grass dep from gdal; adding gdal-grass driver as gdal plugin (upstream 
approved).

Thx Steve, this one is ready for GLSA

GLSA Batch ready

GLSA 200511-02