Bug#756867: transition: gdal
On 06/19/2015 01:21 PM, Emilio Pozuelo Monfort wrote:
> On 17/06/15 01:22, Sebastiaan Couwenberg wrote:
>> 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.
>
> OK.
>
>> 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.
>
> I don't mind either way.
>
> You can try to educate your upstream to not break the ABI at every release
> (especially at minor / point releases). Though unfortunately some upstreams
> don't care much about ABI stability...
The C API is pretty stable, the combination of the both the C & C++ API
in the same library makes it more difficult to deal with for gdal. Other
GIS projects like GEOS and libLAS a separate C & C++ libraries, that may
be a good idea for GDAL too.
It's unfortunate that one of the facts documented in the README.Debian
for gdal is not true anymore:
"
- 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.
"
The alternative dependency template for the C++ symbols shows that most
reverse dependencies don't limit themselves to the C API only.
I'm not well versed enough in the subject matter to educate upstream
about it. I therefor very much appreciate the help I've received in this
and earlier gdal transitions to improve the situation for the gdal
package in Debian.
>>>> 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.
>
> ACK. I have updated the transition tracker for that.
Thanks for the tracker update.
The updated gdal package was uploaded yesterday and is currently in NEW
because of the library package rename:
https://ftp-master.debian.org/new/gdal_1.11.2+dfsg-1~exp4.html
>> 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.
>
> OK. The name doesn't matter much. And I don't mind all that much if you go
> through Provides or through renaming the binary package. Your call.
I'm tempted to reconsider the approach again, but I won't. I'll stick to
the chosen path now that I'm finally convinced the best approach is
taken with the package rename + alternative dependency template.
>>>> 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.
>
> This conflicts with the (uncoordinated) mapnik transition, which is currently
> stalled due to #788533. I see that is maintained by the same team as gdal, so
> maybe you can take a look or ping the right people? gdal can probably go after
> that, if no other issues arise.
I briefly raised the issue of the uncoordinated mapnik transition,
mostly because Jérémy initially marked the upload for experimental.
See:
http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2015-May/030706.html
https://lists.debian.org/debian-gis/2015/05/msg00044.html
The mips* FTBFS are a recurring problem for the mapnik package, previous
builds were no different. I'll try to get it to build on a porterbox,
but I expect intervention from the buildd admins will be required like
last time to make sure only the buildds with the most resources try to
build mapnik.
See: https://bugs.debian.org/742149
https://bugs.debian.org/729121
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: