Hi folks in experimental I'm exploiting the possibility of adopting symbol tracking in order to avoid the perennial reissuing of a new versioned source package at every new major release, with the costly binNMU jobs batching, which is quite annoying.
Basically this is a well-known and quite old problem, due to possible breakage of the C++ interface from one version to another. The C++ classes are exported and mixed up with the very stable C API within the same library. My idea is using version tracking (see [1]) starting from 1.8.1 version for both C and C++ global symbols and possibly a version script [2] to add a suitable symbol versioning (e.g. @GDAL_1.8 for current 1.8.1 version) at each new release (with possibly source patches whenever breakages would happen). My aim is dropping source versioning in packages and returning to a more sane and simple libgdal<SONAME> binary, with a conventional -lgdal as linking argument and so on. That will require another final round of binNMUs to normalize the archive. At the same time, 1.8.1 will be the first version which should solve the old problem of linking both geotiff, tiff and gdal within the same binary, something that annoyed since years Orfeotoolbox folks and possibly others. Note: the new library will NOT be binary-compatible with third-parties closed binaries. At least, I know it will probably be not more compatible with GAMMA SAR and Interferometry Software [3] which does not distribute its own copy of gdal. Ideas and comments? [1] http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps [2] http://sourceware.org/binutils/docs/ld/VERSION.html#VERSION [3] http://www.gamma-rs.ch/no_cache/software.html -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
