Hi Petter, On Wed, Jan 04, 2006 at 03:14:52PM +0100, Petter Reinholdtsen wrote: > > [Silke Reimer] > > No. I mean, that libgdal1 should be renamed to libgdal2 when the > > soname changes the next one will be libgdal3 etc. Thus having > > libgdal1-dev and libgdal1 and (for version 1.3.1 of gdal) libgdal2 > > and libgdal2-dev etc. > > Right. Did you follow the discussion about the lack of C++ ABI > stability in gdal? C++ programs linked with version 1.3.1 of gdal is > not garanteed to work with version 1.3.2 of gdal, even though the > soname stay the same. To avoid breaking installed packages, we thus > need to make sure the library package changes name with every new > upstream release of gdal. Yes, I followed the discussion. In my opinion: If there is some part of the whole library (in this case the part that is C++ which seems not to be easily seperable from the C-part) which is not fully compatible to the old version the soname *should* change. And your are right: The package name has to reflect that (I made a proposition to that in my last email. > > But as far as I know, the API should be backward compatible, so it > should be safe to have a libgdal-dev package without version numbers > in them, to make it easier to rebuild packages build-depending on > gdal. > > > _______________________________________________ > Pkg-grass-general mailing list > Pkg-grass-general@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-general -- 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