Bug#756867: transition: gdal
On 13/08/14 18:51, Sebastiaan Couwenberg wrote:
> On 08/13/2014 06:18 PM, Julien Cristau wrote:
>> On Wed, Aug 13, 2014 at 11:45:36 +0200, Sebastiaan Couwenberg wrote:
>>
>>> All I know is that we need to rebuild the reverse dependencies for a new
>>> GDAL version, even if the SONAME doesn't change. libLAS even needed
>>> source changes to support GDAL 1.11.0 (since it uses the unstable C++
>>> interface).
>>>
>>> README.source in gdal documents the following:
>>>
>>> "
>>> - the C interface is considered stable, but it adds new functions at
>>> every new release.
>>> - the C++ interface is considered unstable and adds/removes/changes
>>> methods at every new minor/major release. That implies both API/ABI
>>> changes at every new release, possibly.
>>> - both C and C++ APIs coexists in the same library with a unique
>>> SONAME (the C one).
>>> - the only official API that should be used by all programs is the C
>>> one. At the moment this is generally respected, so forcing a library
>>> migration should be considered pointless in general.
>>> "
>>>
>> OK, I'd suggest something like this:
>> - add Provides: libgdal.so.1-${version} to libgdal1h (${version} being
>> 1.10.1 or 1.11.0)
>> - adjust libgdal1h.symbols.* to generate a dep on
>> libgdal.so.1-${version} for all c++ symbols
>>
>> That way it's clear from the packaging metadata what uses only the
>> stable C interface and what uses the unstable C++ one, and we know what
>> to rebuild. Does that seem plausible?
>
> Thanks for the helpful suggestion, it sounds like a nice solution.
Indeed. That sounds somewhat similar to what qtbase-opensource-src does, with
the Provides: qtbase-abi-5-3-1 (that change whenever the ABI changes).
> I'll have a look at implementing it.
You can probably use dependency-templates on the symbols file, adding a
libgdal-1.10.1 template and making all the c++ symbols have a dependency on it.
See the "Advanced symbols file" on deb-symbols(5).
Emilio
Reply to: