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 attachment 69704 [details, diff] 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 attachment 69708 [details, diff] gdal-1.2.6-installpathfix.patch
Created attachment 69709 [details, diff] 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