[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#756867: transition: gdal



On 14/06/15 13:28, Sebastiaan Couwenberg wrote:
> On 06/14/2015 04:29 AM, Julien Cristau wrote:
>> On Fri, Jun 12, 2015 at 17:39:14 +0200, Sebastiaan Couwenberg
>> wrote:
>>
>>> This hasn't been an issue before, so I'm tempted to ignore it.
>>> Unless the Release Team wants this addressed, then we'll need to
>>> update gdal in jessie first.
>>>
>> It needs to be addressed, with no changes in jessie.  That
>> probably means changing the libgdal binary package name, AIUI.
> 
> OK, since changing the package name is now required for each patch
> release of GDAL,

Why? It is only required now because your rdeps don't have strict dependencies
for the C++ symbols, and you're breaking that. Once they have strict
dependencies, you don't need to rename the package, just change the Provides:
gdal-abi-1-11-0, and rebuild the rdeps that depend on that (i.e. the C++ rdeps).

> having the alternative dependency for the C++ symbols
> doesn't have much benefit anymore.

It still does. The package rename is a one time thing to ensure that all your
C++ rdeps get proper strict dependencies and they don't break whenever you break
your ABI (because they would depend on gdal-abi-1-11-0 and for say 1.11.1, you
change the provides to gdal-1-11-1, and so the libgdal package can't be upgraded
unless the rdeps are upgraded too). See e.g. what qtbase-opensource-src
(libqt5core5a binary) does with its Provides: qtbase-abi-*.

> It may be better to just include
> the upstream version in the package name (e.g. libgdal1-1.11.2 &
> libgdal20-2.0.0) and drop the alternative dependency for the C++ symbols.

That's possible, but it's not better.

> GDAL upstream started a vote to bless GDAL 2.0.0 RC1 as final, so the
> final release is expected soon. I've started packaging the
> pre-releases but I expect we'll need to resolve quite a number of
> issues in the reverse dependencies to work with GDAL 2.0.0 before we
> can consider it for unstable.
> 
> With that in mind I still prefer to first move GDAL 1.11.2 from
> experimental to unstable so we can use experimental for GDAL 2.0.0. It
> does mean another gdal transition in the near future for 1.11 -> 2.0.

There would be another transition for the 1.11 -> 2.0 update, but only involving
the C++ rdeps (assuming the C ABI stays stable). But either way that's not a
problem. If 1.11 is ready now, let's do that first.

Cheers,
Emilio


Reply to: