On Mon, Jan 09, 2006 at 02:02:01PM +0100, Francesco P. Lovergine wrote: > On Mon, Jan 09, 2006 at 07:09:48AM -0500, Frank Warmerdam wrote: > > On 1/7/06, Silke Reimer <Silke.Reimer@intevation.de> wrote: > > > I would vote to stick to our decission about the package name but adapt > > > the soname of libgdal to have an minor and subversion, so that the full > > > soname is 1.3.1 instead of 1. This will have the advantage that there > > > isn't any need to rebuild qgis or other package just because a new gdal > > > version is present since its concurrent installation on the same system > > > is possible. > > > > > > It requires though that Frank changes the soname each time he releases a > > > new gdal version - which isn't too difficult I think. So we need some > > > feedback from you, Frank. > > > > Silke, > > > > I am not adverse to the soname changing for each version > > on Debian, but I think that should be a debian specific > > patch, not something done upstream. > > > > For my purposes (in the general context) the soname and > > versioning are about the C API, not the C++ API, and that > > is why I don't want to change this upstream. I do realize that > > for the sake of proper version selection re: MapServer and QGIS > > you need distinct libraries as the C++ ABI alters but I don't > > wish to do that in general for GDAL. OK. We have to accept this though we will have the same problem with other distributions as well (as Fedora for example where gdal is not far from being accepted for Fedora Extra). Since I am not keen to use sonames on a system that are not supported by upstream I vote for renaming the library itself: instead of libgdal.so we should have libgdal<gdalversion>.so This would require to patch mapserver, qgis etc. so that they link against libgdal<gdalversion> instead of libgdal. The package name should be libgdal1-<gdalversion> resp. libgdal1-<gdalversion>-dev as we already decided last week. What do you think? > > > > Why not splitting C and C++ libs? As far as I understood we all agreed that this would be a good solution but is something for midterm because right now there isn't anybody who has enough time to actually do it. In my opinion it would be the better solutions though. Silke -- Intevation GmbH Georgstrasse 4 49074 Osnabrück, Germany http://intevation.de http://intevation.de/~silke FreeGIS.org http://freegis.org/
Attachment:
signature.asc
Description: Digital signature