Bug#756867: transition: gdal
On 06/16/2015 01:21 AM, Emilio Pozuelo Monfort wrote:
> 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).
Not changing the package name at every patch release is good to avoid
lengthy delays through the NEW queue.
But I don't see much practical difference between having the upstream
version in the package name and have the alternative dependency template
on the C++ symbols. Most gdal rdeps depend on some C++ symbols, there
are only a few that don't need a rebuild at every new patch release.
It seemed easier to append the version to the package name, combining
the SONAME derived package name for the C library and the -<version> for
the C++ library like for do for geos for instance.
>> 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.
OK, I'll keep the alternative dependency template for the C++ symbols
and change the package name. libgdal1i seems an obvious choice to
succeed libgdal1h.
I'll stick to the libgdal.so.1-1.11.2 virtual package that was initially
suggest in this transition bug to not break the gdal 1.11.2 as included
in Ubuntu.
Switching to the more common naming convention of gdal-abi-2-0-0 for
GDAL 2.0 seems like a good idea.
>> 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.
1.11 has been ready for quite some time now, I'd like to get it into
unstable as soon as possible.
Because of the package rename, the next upload will have to pass the NEW
queue again. Can you ask an FTP Assistant to review the binary-NEW gdal
soon after its upload to not have another couple of months delay before
this transition can be started? They seem more receptive to these
requests from the Release Team.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: