Summary: | sci-libs/gdal appeas to have RPATH issues | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | Jason Wever (RETIRED) <weeve> | ||||||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | normal | CC: | dragonheart, nerdboy, sci | ||||||||
Priority: | High | ||||||||||
Version: | unspecified | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | B2 [glsa] | ||||||||||
Package list: | Runtime testing required: | --- | |||||||||
Bug Depends on: | |||||||||||
Bug Blocks: | 81745 | ||||||||||
Attachments: |
|
Description
Jason Wever (RETIRED)
2005-09-12 21:39:50 UTC
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 |