[Ubuntu] piuparts gdal

[Sebastiaan Couwenberg]

On 10/28/2014 11:16 PM, Johan Van de Wauw wrote:
> On Tue, Oct 21, 2014 at 11:10 PM, Sebastiaan Couwenberg
> <sebastic at xs4all.nl> wrote:
>> I'm not too worried about these failure yet, there is still more to do
>> for the GDAL 1.11.1 packaging.
>>
> Can you comment on that further? Usually ubuntugis updates
> repositories after each release of ubuntu. Should we upgrade to GDAL
> 1.11.1 or should we wait and stay at 1.11?
> 
> What are the remaining issues? Something someone else may help with?

In general gdal-grass 1.11.1 still needs to be built and all other
reverse depedencies need to be tested to verify that they still work.

For gdal-grass to be built we first need to get gdal rebuild in
experimental to fix the jpeg-turbo dependency, see: #764951 & #766694.

Specifically for gdal packaging the symbols need to be updated for the
various architectures, but it's still not built on mips. I may update
the symbols for the other archs soonish, so that the release team
doesn't need to binnmu gdal in experimental anymore because I'll do a
new upload to it containing the symbols change.

In UbuntuGIS you may or may not want the alternative dependency change
that was introduced after feedback from the Release Team. Because the
C++ symbols change at every release (even minor point releases), all
rdeps that use the C++ symbols need to be rebuilt. To track which
packages use the C++ symbols, those packages depends on libgdal1h and
libgdal.so.1-<VERSION> which is provided by libgdal1h. See #756867.

It's up to the UbuntuGIS maintainers to update to GDAL 1.11.1 or stay at
1.11.0. You can rely on proven package versions from Debian, or you can
explore what may break when you update. Since there are only two new C++
symbols (on amd64) and this is a not a major new release like 1.11.0 was
there shouldn't be any breakage, but you don't know for sure until all
rdeps have been rebuilt.

I welcome help with bug triage. For instance, to fix #745702 we'll need
a non-free source package that downloads the gdal tarball and extracts
the non-free data files that were removed from the gdal package in main.
Or debug why GDAL >1.9 is so much slower to create spatialite databases
as reported in #746566.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1