Debian Bug report logs - #756867
transition: gdal

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Bas Couwenberg <sebastic@xs4all.nl>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: transition: gdal

Date: Sat, 02 Aug 2014 20:41:59 +0200

Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

Dear Release Team,

The Debian GIS team would like to get GDAL 1.11.0 into jessie before the
freeze.

Currently GDAL 1.10.1 is unstable and jessie, and GDAL 1.11.0 is in
experimental.

Updating GDAL from 1.10.1 to 1.11.0 involves a SONAME bump from
libgdal.so.1.17.1 to libgdal.so.1.18.0.

Because the binary package name doesn't change, I don't know how to
format a Ben file to track this.

I've rebuild all reverse dependencies to verify that they still build
successfully with GDAL 1.11.0.

Initially libLAS FTBFS but we have backported the GDAL 1.11.0 support from
libLAS 1.8 to 1.7.

All reverse dependencies only need binNMUs now.

Because of the upcoming HDF5 transition it's currently not possible to
build ncl because its build dependencies cannot be satisfied:

 The following packages have unmet dependencies:
  libhe5-hdfeos0 : Depends: libhdf5-8 which is a virtual package.

libgdal-grass 1.11.0 is also available in experimental, and will be
uploaded to unstable together with gdal.

The status of the most recent rebuilds is as follows.

 dans-gdal-scripts  (0.23-2)                     OK
 grass              (6.4.3-3)                    OK
 liblas             (1.7.0+dfsg-6)               OK
 mapnik             (2.2.0+ds1-7)                OK
 mapserver          (6.4.1-5)                    OK
 merkaartor         (0.18.1-3)                   OK
 ncl                (6.2.0-2)                    BD-Uninstallable
 node-srs           (0.3.2+ds1-1)                OK
 openscenegraph     (3.2.0~rc1-5.1 / 3.2.1-1)    OK / OK
 osmium             (0.0~20111213-g7f3500a-3.1)  OK
 postgis            (2.1.3+dfsg-3)               OK
 qlandkartegt       (1.7.7-2)                    OK
 sumo               (0.21.0+dfsg-1)              OK
 thuban             (1.2.2-5)                    OK
 vtk6               (6.1.0+dfsg-8)               OK
 xastir             (2.0.4-2)                    OK
 libcitygml         (0.14+svn134-1+3p2p0)        OK
 libgdal-grass      (1.10.1-2)                   N/A
 mapcache           (1.2.1-2)                    OK
 osgearth           (2.5.0+dfsg-2)               OK
 saga               (2.1.2+dfsg-1)               OK
 qgis               (2.2.0-1 / 2.4.0-1~exp1)     OK / OK
 pktools            (2.5.2+20140505-1)           OK

Kind Regards,

Bas

Message #10 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Bas Couwenberg <sebastic@xs4all.nl>, 756867@bugs.debian.org

Subject: Re: Bug#756867: transition: gdal

Date: Tue, 12 Aug 2014 11:26:22 +0200

On 02/08/14 20:41, Bas Couwenberg wrote:
> Updating GDAL from 1.10.1 to 1.11.0 involves a SONAME bump from
> libgdal.so.1.17.1 to libgdal.so.1.18.0.
> 
> Because the binary package name doesn't change, I don't know how to
> format a Ben file to track this.

Err. What? Are you bumping the SONAME without renaming the package? Why? Why
isn't the package named after the SONAME as it should be? What am I missing?

Emilio

Message #15 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 756867@bugs.debian.org

Subject: Re: Bug#756867: transition: gdal

Date: Tue, 12 Aug 2014 11:41:57 +0200

On 08/12/2014 11:26 AM, Emilio Pozuelo Monfort wrote:
> On 02/08/14 20:41, Bas Couwenberg wrote:
>> Updating GDAL from 1.10.1 to 1.11.0 involves a SONAME bump from
>> libgdal.so.1.17.1 to libgdal.so.1.18.0.
>>
>> Because the binary package name doesn't change, I don't know how to
>> format a Ben file to track this.
> 
> Err. What? Are you bumping the SONAME without renaming the package? Why? Why
> isn't the package named after the SONAME as it should be? What am I missing?

Sorry about creating such confusion by badly wording the issue.

The SONAME doesn't change, it remains at libgdal.so.1, only the library
version changes.

The package is named libgdal1h to differentiate it from its predecessor
libgdal1 after the reintroduction of internal symbols hiding for better
compatibility against mixing external geotiff and gdal.

Because the libgdal exposes both C and C++ symbols, its reverse
dependencies need a rebuild to make sure they continue to work in case
they don't only use the stable C API but also the unstable C++ API.

Does it make sense to you now?

> Emilio

Kind Regards,

Bas

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

Message #20 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>, 756867@bugs.debian.org

Cc: Emilio Pozuelo Monfort <pochu@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Tue, 12 Aug 2014 17:41:06 -0700

[Message part 1 (text/plain, inline)]

On Tue, Aug 12, 2014 at 11:41:57 +0200, Sebastiaan Couwenberg wrote:

> On 08/12/2014 11:26 AM, Emilio Pozuelo Monfort wrote:
> > On 02/08/14 20:41, Bas Couwenberg wrote:
> >> Updating GDAL from 1.10.1 to 1.11.0 involves a SONAME bump from
> >> libgdal.so.1.17.1 to libgdal.so.1.18.0.
> >>
> >> Because the binary package name doesn't change, I don't know how to
> >> format a Ben file to track this.
> > 
> > Err. What? Are you bumping the SONAME without renaming the package? Why? Why
> > isn't the package named after the SONAME as it should be? What am I missing?
> 
> Sorry about creating such confusion by badly wording the issue.
> 
> The SONAME doesn't change, it remains at libgdal.so.1, only the library
> version changes.
> 
> The package is named libgdal1h to differentiate it from its predecessor
> libgdal1 after the reintroduction of internal symbols hiding for better
> compatibility against mixing external geotiff and gdal.
> 
> Because the libgdal exposes both C and C++ symbols, its reverse
> dependencies need a rebuild to make sure they continue to work in case
> they don't only use the stable C API but also the unstable C++ API.
> 
> Does it make sense to you now?
> 
It doesn't to me...  You seem to be mixing up API and ABI, so I'm not
sure what you're saying.

Cheers,
Julien

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Julien Cristau <jcristau@debian.org>, 756867@bugs.debian.org

Cc: Emilio Pozuelo Monfort <pochu@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Wed, 13 Aug 2014 11:45:36 +0200

On 08/13/2014 02:41 AM, Julien Cristau wrote:
> On Tue, Aug 12, 2014 at 11:41:57 +0200, Sebastiaan Couwenberg wrote:
> 
>> On 08/12/2014 11:26 AM, Emilio Pozuelo Monfort wrote:
>>> On 02/08/14 20:41, Bas Couwenberg wrote:
>>>> Updating GDAL from 1.10.1 to 1.11.0 involves a SONAME bump from
>>>> libgdal.so.1.17.1 to libgdal.so.1.18.0.
>>>>
>>>> Because the binary package name doesn't change, I don't know how to
>>>> format a Ben file to track this.
>>>
>>> Err. What? Are you bumping the SONAME without renaming the package? Why? Why
>>> isn't the package named after the SONAME as it should be? What am I missing?
>>
>> Sorry about creating such confusion by badly wording the issue.
>>
>> The SONAME doesn't change, it remains at libgdal.so.1, only the library
>> version changes.
>>
>> The package is named libgdal1h to differentiate it from its predecessor
>> libgdal1 after the reintroduction of internal symbols hiding for better
>> compatibility against mixing external geotiff and gdal.
>>
>> Because the libgdal exposes both C and C++ symbols, its reverse
>> dependencies need a rebuild to make sure they continue to work in case
>> they don't only use the stable C API but also the unstable C++ API.
>>
>> Does it make sense to you now?
>>
> It doesn't to me...  You seem to be mixing up API and ABI, so I'm not
> sure what you're saying.

I think I did that before, and I must admit that ABIs are not my area of
expertise.

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.
"

Since the previous gdal transition was not well coordinated with the
release team, I'd like to prevent an uncoordinated upload to unstable
this time.

Since only binNMUs are required with the updated libLAS in the archive,
maybe a transition is the wrong way to go about this, and instead we
(the Debian GIS team) should upload GDAL 1.11.0 to unstable when we're
ready and request the binNMUs afterward?

> Cheers,
> Julien

Kind Regards,

Bas

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

Message #30 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>, 756867@bugs.debian.org

Cc: Emilio Pozuelo Monfort <pochu@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Wed, 13 Aug 2014 09:18:34 -0700

[Message part 1 (text/plain, inline)]

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?

Cheers,
Julien

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Julien Cristau <jcristau@debian.org>, 756867@bugs.debian.org

Cc: Emilio Pozuelo Monfort <pochu@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Wed, 13 Aug 2014 18:51:01 +0200

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.

I'll have a look at implementing it.

> Cheers,
> Julien

Kind Regards,

Bas

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

Message #40 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>, Julien Cristau <jcristau@debian.org>, 756867@bugs.debian.org

Subject: Re: Bug#756867: transition: gdal

Date: Wed, 13 Aug 2014 23:22:15 +0200

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

Message #45 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 756867@bugs.debian.org, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Thu, 11 Sep 2014 22:39:05 +0200

On 08/13/2014 11:22 PM, Emilio Pozuelo Monfort wrote:
> On 13/08/14 18:51, Sebastiaan Couwenberg wrote:
>> On 08/13/2014 06:18 PM, Julien Cristau wrote:
>>> 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).

I've implemented the alternative dependency template in the latest
revision of gdal 1.11.0, and I've done a rebuild of all rdeps to see
which of them use C++ symbols.

Most packages use the alternative dependency template. The source
packages for grass, mapserver, ncl, openscenegraph (3.2.0~rc1-5.1),
postgis, vtk, xastir and mapcache don't use any C++ symbols.

It's interesting that the openscenegraph version in experimental does
use some gdal C++ symbols, but the version in unstable does not.

If we want to use this feature to track the GDAL 1.11.0 transition we'll
need to implement it in GDAL 1.10.1 too and binNMU all the rdeps. The
ben file for the 1.11.0 transition could then be:

 title = "libgdal1h";
 is_affected = .depends ~ /libgdal.so.1-1.10.1/;
 is_good = .depends ~ /libgdal.so.1-1.11.0/;
 is_bad = .depends ~ /libgdal.so.1-1.10.1/;

But this would exclude vtk6 which uses symbols introduced in 1.11.0 when
built with it. So I'm not sure if this is the right way forward. Keeping
all packages build depending on libgdal-dev as affected and not
explicitly marking the packages that don't use C++ symbols as good may
be an option.

Would that be acceptable for the Release Team?


The dependency results for the binary packages:

 dans-gdal-scripts           libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)

 grass-core                  libgdal1h (>= 1.8.0)

 liblas3                     libgdal.so.1-1.11.0, libgdal1h (>= 1.10.1)
 liblas-c3                   libgdal1h (>= 1.8.0)
 liblas-bin                  libgdal1h (>= 1.8.0)

 libmapnik2.2                libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 cgi-mapserver               libgdal1h (>= 1.8.0)
 libmapserver1               libgdal1h (>= 1.9.0)
 mapserver-bin               libgdal1h (>= 1.8.0)
 libmapscript-java           libgdal1h (>= 1.8.0)
 libmapscript-perl           libgdal1h (>= 1.8.0)
 python-mapscript            libgdal1h (>= 1.8.0)
 ruby-mapscript              libgdal1h (>= 1.8.0)

 merkaartor                  libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 ncl-ncarg                   libgdal1h (>= 1.8.0)

 node-srs                    libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)

 libopenscenegraph99         libgdal1h (>= 1.11.0)
 libopenscenegraph100        libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 osmium                      build depends on libgdal-dev, but none of
                             the binary packages have a dependency on
                             libgdal1h

 postgis                     libgdal1h (>= 1.9.0)
 postgresql-9.4-postgis-2.1  libgdal1h (>= 1.9.0)

 qlandkartegt                libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)

 sumo                        libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 thuban                      libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)

 libvtk6.1                   libgdal1h (>= 1.11.0)

 xastir                      libgdal1h (>= 1.8.0)

 libcitygml0                 libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)
 libcitygml0-bin             libgdal1h (>= 1.8.0)
 openscenegraph-plugin-citygml-shared
                             libgdal1h (>= 1.8.0)

 libgdal1-1.11.0-grass       libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 libapache2-mod-mapcache     libgdal1h (>= 1.8.0)
 libmapcache1                libgdal1h (>= 1.8.0)
 mapcache-cgi                libgdal1h (>= 1.8.0)
 mapcache-tools              libgdal1h (>= 1.8.0)

 libosgearth3                libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)
 libosgearthannotation3      libgdal1h (>= 1.8.0)
 libosgearthfeatures3        libgdal1h (>= 1.8.0)
 libosgearthqt3              libgdal1h (>= 1.8.0)
 libosgearthsymbology3       libgdal1h (>= 1.8.0)
 libosgearthutil3            libgdal1h (>= 1.8.0)
 openscenegraph-plugin-osgearth
                             libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)
 osgearth                    libgdal1h (>= 1.8.0)

 saga                        libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

 libqgis-analysis2.2.0       libgdal1h (>= 1.8.0)
 libqgis-core2.2.0           libgdal1h (>= 1.8.0)
 libqgisgrass2.2.0           libgdal1h (>= 1.8.0)
 libqgis-gui2.2.0            libgdal1h (>= 1.8.0)
 libqgis-networkanalysis2.2.0
                             libgdal1h (>= 1.8.0)
 libqgispython2.2.0          libgdal1h (>= 1.8.0)
 libqgissqlanyconnection2.2.0
                             libgdal1h (>= 1.8.0)
 python-qgis                 libgdal1h (>= 1.8.0)
 qgis                        libgdal.so.1-1.11.0, libgdal1h (>= 1.8.0)
 qgis-mapserver              libgdal1h (>= 1.8.0)
 qgis-plugin-globe           libgdal1h (>= 1.8.0)
 qgis-plugin-grass           libgdal1h (>= 1.8.0)
 qgis-providers              libgdal1h (>= 1.11.0)
 qgis-sqlanywhere            libgdal1h (>= 1.8.0)

 pktools:                    libgdal.so.1-1.11.0, libgdal1h (>= 1.11.0)

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

Message #50 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 756867@bugs.debian.org, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Tue, 26 May 2015 23:16:25 +0200

Dear Release Team,

To move away from the deprecated spatialite_init() method that is
causing issues since the proj 4.9.1 transition (#785091) we need to get
gdal 1.11.2 out of experimental.

We didn't manage to get it into jessie, so I'd like to restart this
transition for stretch as soon as possible.

There is still an outstanding question of how to best track the transition.

On 09/11/2014 10:39 PM, Sebastiaan Couwenberg wrote:
> On 08/13/2014 11:22 PM, Emilio Pozuelo Monfort wrote:
>> On 13/08/14 18:51, Sebastiaan Couwenberg wrote:
>>> On 08/13/2014 06:18 PM, Julien Cristau wrote:
>>>> 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).
> 
> I've implemented the alternative dependency template in the latest
> revision of gdal 1.11.0, and I've done a rebuild of all rdeps to see
> which of them use C++ symbols.
> 
> Most packages use the alternative dependency template. The source
> packages for grass, mapserver, ncl, openscenegraph (3.2.0~rc1-5.1),
> postgis, vtk, xastir and mapcache don't use any C++ symbols.
> 
> It's interesting that the openscenegraph version in experimental does
> use some gdal C++ symbols, but the version in unstable does not.
> 
> If we want to use this feature to track the GDAL 1.11.0 transition we'll
> need to implement it in GDAL 1.10.1 too and binNMU all the rdeps. The
> ben file for the 1.11.0 transition could then be:
> 
>  title = "libgdal1h";
>  is_affected = .depends ~ /libgdal.so.1-1.10.1/;
>  is_good = .depends ~ /libgdal.so.1-1.11.0/;
>  is_bad = .depends ~ /libgdal.so.1-1.10.1/;
> 
> But this would exclude vtk6 which uses symbols introduced in 1.11.0 when
> built with it. So I'm not sure if this is the right way forward. Keeping
> all packages build depending on libgdal-dev as affected and not
> explicitly marking the packages that don't use C++ symbols as good may
> be an option.
> 
> Would that be acceptable for the Release Team?

With the above in mind I suggest the following ben configuration:

 title = "libgdal1h";
 is_affected = .build-depends ~ /libgdal1?-dev/;
 is_good = .depends ~ /libgdal.so.1-1.11.2/;
 is_bad = .depends ~ /libgdal.so.1-1.10.1/;

No packages will be marked as bad, but those that use the C++ symbols
will be marked as good.

Is this acceptable?

I've done a new round of rebuilds for the gdal reverse dependencies, all
build fine with the new version. The rebuilds uncovered an unrelated
FTBFS in osgearth which was fixed last weekend. See:

https://lists.debian.org/debian-gis/2015/05/msg00041.html

Kind Regards,

Bas

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

Message #55 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>, 756867@bugs.debian.org, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Sun, 31 May 2015 15:19:00 +0200

Control: forwarded -1 https://release.debian.org/transitions/html/gdal-1.11.html

On 26/05/15 23:16, Sebastiaan Couwenberg wrote:
> Dear Release Team,
> 
> To move away from the deprecated spatialite_init() method that is
> causing issues since the proj 4.9.1 transition (#785091) we need to get
> gdal 1.11.2 out of experimental.
> 
> We didn't manage to get it into jessie, so I'd like to restart this
> transition for stretch as soon as possible.
> 
> There is still an outstanding question of how to best track the transition.
> 
> On 09/11/2014 10:39 PM, Sebastiaan Couwenberg wrote:
>> On 08/13/2014 11:22 PM, Emilio Pozuelo Monfort wrote:
>>> On 13/08/14 18:51, Sebastiaan Couwenberg wrote:
>>>> On 08/13/2014 06:18 PM, Julien Cristau wrote:
>>>>> 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).
>>
>> I've implemented the alternative dependency template in the latest
>> revision of gdal 1.11.0, and I've done a rebuild of all rdeps to see
>> which of them use C++ symbols.
>>
>> Most packages use the alternative dependency template. The source
>> packages for grass, mapserver, ncl, openscenegraph (3.2.0~rc1-5.1),
>> postgis, vtk, xastir and mapcache don't use any C++ symbols.
>>
>> It's interesting that the openscenegraph version in experimental does
>> use some gdal C++ symbols, but the version in unstable does not.
>>
>> If we want to use this feature to track the GDAL 1.11.0 transition we'll
>> need to implement it in GDAL 1.10.1 too and binNMU all the rdeps. The
>> ben file for the 1.11.0 transition could then be:
>>
>>  title = "libgdal1h";
>>  is_affected = .depends ~ /libgdal.so.1-1.10.1/;
>>  is_good = .depends ~ /libgdal.so.1-1.11.0/;
>>  is_bad = .depends ~ /libgdal.so.1-1.10.1/;
>>
>> But this would exclude vtk6 which uses symbols introduced in 1.11.0 when
>> built with it. So I'm not sure if this is the right way forward. Keeping
>> all packages build depending on libgdal-dev as affected and not
>> explicitly marking the packages that don't use C++ symbols as good may
>> be an option.
>>
>> Would that be acceptable for the Release Team?
> 
> With the above in mind I suggest the following ben configuration:
> 
>  title = "libgdal1h";
>  is_affected = .build-depends ~ /libgdal1?-dev/;
>  is_good = .depends ~ /libgdal.so.1-1.11.2/;
>  is_bad = .depends ~ /libgdal.so.1-1.10.1/;

I have created https://release.debian.org/transitions/html/gdal-1.11.html

> No packages will be marked as bad, but those that use the C++ symbols
> will be marked as good.
> 
> Is this acceptable?

So what do you propose here? Should we rebuild only those packages that use any
of the C++ symbols? If so, do you have a list?

Cheers,
Emilio

Message #62 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 756867@bugs.debian.org, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Sun, 31 May 2015 15:59:40 +0200

On 05/31/2015 03:19 PM, Emilio Pozuelo Monfort wrote:
> On 26/05/15 23:16, Sebastiaan Couwenberg wrote:
>> Dear Release Team,
>>
>> To move away from the deprecated spatialite_init() method that is
>> causing issues since the proj 4.9.1 transition (#785091) we need to get
>> gdal 1.11.2 out of experimental.
>>
>> We didn't manage to get it into jessie, so I'd like to restart this
>> transition for stretch as soon as possible.
>>
>> There is still an outstanding question of how to best track the transition.
>>
>> On 09/11/2014 10:39 PM, Sebastiaan Couwenberg wrote:
>>> On 08/13/2014 11:22 PM, Emilio Pozuelo Monfort wrote:
>>>> On 13/08/14 18:51, Sebastiaan Couwenberg wrote:
>>>>> On 08/13/2014 06:18 PM, Julien Cristau wrote:
>>>>>> 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).
>>>
>>> I've implemented the alternative dependency template in the latest
>>> revision of gdal 1.11.0, and I've done a rebuild of all rdeps to see
>>> which of them use C++ symbols.
>>>
>>> Most packages use the alternative dependency template. The source
>>> packages for grass, mapserver, ncl, openscenegraph (3.2.0~rc1-5.1),
>>> postgis, vtk, xastir and mapcache don't use any C++ symbols.
>>>
>>> It's interesting that the openscenegraph version in experimental does
>>> use some gdal C++ symbols, but the version in unstable does not.
>>>
>>> If we want to use this feature to track the GDAL 1.11.0 transition we'll
>>> need to implement it in GDAL 1.10.1 too and binNMU all the rdeps. The
>>> ben file for the 1.11.0 transition could then be:
>>>
>>>  title = "libgdal1h";
>>>  is_affected = .depends ~ /libgdal.so.1-1.10.1/;
>>>  is_good = .depends ~ /libgdal.so.1-1.11.0/;
>>>  is_bad = .depends ~ /libgdal.so.1-1.10.1/;
>>>
>>> But this would exclude vtk6 which uses symbols introduced in 1.11.0 when
>>> built with it. So I'm not sure if this is the right way forward. Keeping
>>> all packages build depending on libgdal-dev as affected and not
>>> explicitly marking the packages that don't use C++ symbols as good may
>>> be an option.
>>>
>>> Would that be acceptable for the Release Team?
>>
>> With the above in mind I suggest the following ben configuration:
>>
>>  title = "libgdal1h";
>>  is_affected = .build-depends ~ /libgdal1?-dev/;
>>  is_good = .depends ~ /libgdal.so.1-1.11.2/;
>>  is_bad = .depends ~ /libgdal.so.1-1.10.1/;
> 
> I have created https://release.debian.org/transitions/html/gdal-1.11.html
> 
>> No packages will be marked as bad, but those that use the C++ symbols
>> will be marked as good.
>>
>> Is this acceptable?
> 
> So what do you propose here? Should we rebuild only those packages that use any
> of the C++ symbols? If so, do you have a list?

Thanks for creating the tracker.

I suggest to binNMU all affected packages, but only those that use any
C++ symbols will be mark as good in the tracker leaving the others unknown.

Most affected packages use C++ symbols, only grass, mapserver, ncl,
postgis, vtk, xastir and mapcache didn't use any C++ symbols when I
tested this the first time. Curiously openscenegraph (3.2.0~rc1-5.1) in
unstable didn't use C++ symbols but the 3.2.1 version in experimental
did. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756867#45

Kind Regards,

Bas

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

Message #67 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>, 756867@bugs.debian.org, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Fri, 12 Jun 2015 00:26:44 +0200

Hi, and sorry for the late reply.

On 31/05/15 15:59, Sebastiaan Couwenberg wrote:
> On 05/31/2015 03:19 PM, Emilio Pozuelo Monfort wrote:
>> On 26/05/15 23:16, Sebastiaan Couwenberg wrote:
>>> Dear Release Team,
>>>
>>> To move away from the deprecated spatialite_init() method that is
>>> causing issues since the proj 4.9.1 transition (#785091) we need to get
>>> gdal 1.11.2 out of experimental.
>>>
>>> We didn't manage to get it into jessie, so I'd like to restart this
>>> transition for stretch as soon as possible.
>>>
>>> There is still an outstanding question of how to best track the transition.
>>>
>>> On 09/11/2014 10:39 PM, Sebastiaan Couwenberg wrote:
>>>> On 08/13/2014 11:22 PM, Emilio Pozuelo Monfort wrote:
>>>>> On 13/08/14 18:51, Sebastiaan Couwenberg wrote:
>>>>>> On 08/13/2014 06:18 PM, Julien Cristau wrote:
>>>>>>> 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).
>>>>
>>>> I've implemented the alternative dependency template in the latest
>>>> revision of gdal 1.11.0, and I've done a rebuild of all rdeps to see
>>>> which of them use C++ symbols.
>>>>
>>>> Most packages use the alternative dependency template. The source
>>>> packages for grass, mapserver, ncl, openscenegraph (3.2.0~rc1-5.1),
>>>> postgis, vtk, xastir and mapcache don't use any C++ symbols.
>>>>
>>>> It's interesting that the openscenegraph version in experimental does
>>>> use some gdal C++ symbols, but the version in unstable does not.
>>>>
>>>> If we want to use this feature to track the GDAL 1.11.0 transition we'll
>>>> need to implement it in GDAL 1.10.1 too and binNMU all the rdeps. The
>>>> ben file for the 1.11.0 transition could then be:
>>>>
>>>>  title = "libgdal1h";
>>>>  is_affected = .depends ~ /libgdal.so.1-1.10.1/;
>>>>  is_good = .depends ~ /libgdal.so.1-1.11.0/;
>>>>  is_bad = .depends ~ /libgdal.so.1-1.10.1/;
>>>>
>>>> But this would exclude vtk6 which uses symbols introduced in 1.11.0 when
>>>> built with it. So I'm not sure if this is the right way forward. Keeping
>>>> all packages build depending on libgdal-dev as affected and not
>>>> explicitly marking the packages that don't use C++ symbols as good may
>>>> be an option.
>>>>
>>>> Would that be acceptable for the Release Team?
>>>
>>> With the above in mind I suggest the following ben configuration:
>>>
>>>  title = "libgdal1h";
>>>  is_affected = .build-depends ~ /libgdal1?-dev/;
>>>  is_good = .depends ~ /libgdal.so.1-1.11.2/;
>>>  is_bad = .depends ~ /libgdal.so.1-1.10.1/;
>>
>> I have created https://release.debian.org/transitions/html/gdal-1.11.html
>>
>>> No packages will be marked as bad, but those that use the C++ symbols
>>> will be marked as good.
>>>
>>> Is this acceptable?
>>
>> So what do you propose here? Should we rebuild only those packages that use any
>> of the C++ symbols? If so, do you have a list?
> 
> Thanks for creating the tracker.
> 
> I suggest to binNMU all affected packages, but only those that use any
> C++ symbols will be mark as good in the tracker leaving the others unknown.

So let's say gdal 1.11 changed the ABI for some C++ symbols. Since the packages
currently in sid don't have strict dependencies on the old ABI, the new library
will be installed with the old packages, causing breakage.

What do you think about that situation? Should we add the dependency magic to
1.10, rebuild everything, and only then update to 1.11? Or do you think that
case isn't a problem?

Cheers,
Emilio

Message #72 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 756867@bugs.debian.org, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Fri, 12 Jun 2015 01:06:35 +0200

On 06/12/2015 12:26 AM, Emilio Pozuelo Monfort wrote:
> Hi, and sorry for the late reply.
> 
> On 31/05/15 15:59, Sebastiaan Couwenberg wrote:
>> On 05/31/2015 03:19 PM, Emilio Pozuelo Monfort wrote:
>>> On 26/05/15 23:16, Sebastiaan Couwenberg wrote:
>>>> Dear Release Team,
>>>>
>>>> To move away from the deprecated spatialite_init() method that is
>>>> causing issues since the proj 4.9.1 transition (#785091) we need to get
>>>> gdal 1.11.2 out of experimental.
>>>>
>>>> We didn't manage to get it into jessie, so I'd like to restart this
>>>> transition for stretch as soon as possible.
>>>>
>>>> There is still an outstanding question of how to best track the transition.
>>>>
>>>> On 09/11/2014 10:39 PM, Sebastiaan Couwenberg wrote:
>>>>> On 08/13/2014 11:22 PM, Emilio Pozuelo Monfort wrote:
>>>>>> On 13/08/14 18:51, Sebastiaan Couwenberg wrote:
>>>>>>> On 08/13/2014 06:18 PM, Julien Cristau wrote:
>>>>>>>> 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).
>>>>>
>>>>> I've implemented the alternative dependency template in the latest
>>>>> revision of gdal 1.11.0, and I've done a rebuild of all rdeps to see
>>>>> which of them use C++ symbols.
>>>>>
>>>>> Most packages use the alternative dependency template. The source
>>>>> packages for grass, mapserver, ncl, openscenegraph (3.2.0~rc1-5.1),
>>>>> postgis, vtk, xastir and mapcache don't use any C++ symbols.
>>>>>
>>>>> It's interesting that the openscenegraph version in experimental does
>>>>> use some gdal C++ symbols, but the version in unstable does not.
>>>>>
>>>>> If we want to use this feature to track the GDAL 1.11.0 transition we'll
>>>>> need to implement it in GDAL 1.10.1 too and binNMU all the rdeps. The
>>>>> ben file for the 1.11.0 transition could then be:
>>>>>
>>>>>  title = "libgdal1h";
>>>>>  is_affected = .depends ~ /libgdal.so.1-1.10.1/;
>>>>>  is_good = .depends ~ /libgdal.so.1-1.11.0/;
>>>>>  is_bad = .depends ~ /libgdal.so.1-1.10.1/;
>>>>>
>>>>> But this would exclude vtk6 which uses symbols introduced in 1.11.0 when
>>>>> built with it. So I'm not sure if this is the right way forward. Keeping
>>>>> all packages build depending on libgdal-dev as affected and not
>>>>> explicitly marking the packages that don't use C++ symbols as good may
>>>>> be an option.
>>>>>
>>>>> Would that be acceptable for the Release Team?
>>>>
>>>> With the above in mind I suggest the following ben configuration:
>>>>
>>>>  title = "libgdal1h";
>>>>  is_affected = .build-depends ~ /libgdal1?-dev/;
>>>>  is_good = .depends ~ /libgdal.so.1-1.11.2/;
>>>>  is_bad = .depends ~ /libgdal.so.1-1.10.1/;
>>>
>>> I have created https://release.debian.org/transitions/html/gdal-1.11.html
>>>
>>>> No packages will be marked as bad, but those that use the C++ symbols
>>>> will be marked as good.
>>>>
>>>> Is this acceptable?
>>>
>>> So what do you propose here? Should we rebuild only those packages that use any
>>> of the C++ symbols? If so, do you have a list?
>>
>> Thanks for creating the tracker.
>>
>> I suggest to binNMU all affected packages, but only those that use any
>> C++ symbols will be mark as good in the tracker leaving the others unknown.
> 
> So let's say gdal 1.11 changed the ABI for some C++ symbols. Since the packages
> currently in sid don't have strict dependencies on the old ABI, the new library
> will be installed with the old packages, causing breakage.

Rebuilding all affected packages should take care of that.

Isn't the point of a transition to coordinate the upload of the new
library so that the old packages can be rebuilt with it soon after?

The time between the upload of the new library and the rebuild of the
old packages should be minimal, leaving only a short window in which the
old packages may be broken.

> What do you think about that situation? Should we add the dependency magic to
> 1.10, rebuild everything, and only then update to 1.11? Or do you think that
> case isn't a problem?

I don't think it's worth the effort to rebuild all rdepds twice, if
we're going to rebuild them we should just do it for 1.11.

While I'm not entirely happy being unable to mark all affected packages
as good in the tracker, I don't consider it a sufficient problem to add
the alternative dependency to gdal 1.10.1 too.

If there will be a GDAL 1.11.3 after we get 1.11.2 in unstable and
before GDAL 2.0, we can limit the affected packages to those depending
on libgdal.so.1-1.11.2.

Kind Regards,

Bas

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

Message #77 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Vincent Danjean <vdanjean.ml@free.fr>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>, 756867@bugs.debian.org, Emilio Pozuelo Monfort <pochu@debian.org>, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Fri, 12 Jun 2015 07:30:11 +0200

Le 12/06/2015 01:06, Sebastiaan Couwenberg a écrit :
> On 06/12/2015 12:26 AM, Emilio Pozuelo Monfort wrote:
>> So let's say gdal 1.11 changed the ABI for some C++ symbols. Since the packages
>> currently in sid don't have strict dependencies on the old ABI, the new library
>> will be installed with the old packages, causing breakage.
> 
> Rebuilding all affected packages should take care of that.
> 
> Isn't the point of a transition to coordinate the upload of the new
> library so that the old packages can be rebuilt with it soon after?
>
> The time between the upload of the new library and the rebuild of the
> old packages should be minimal, leaving only a short window in which the
> old packages may be broken.

This is true only if the new version of gdal cannot be installed with
old (jessie) version packages using it.
  I do not known anything about gdal. But remember you cannot assume that
users will upgrade in one row from jessie to stretch/testing/unstable.

>> What do you think about that situation? Should we add the dependency magic to
>> 1.10, rebuild everything, and only then update to 1.11? Or do you think that
>> case isn't a problem?
> 
> I don't think it's worth the effort to rebuild all rdepds twice, if
> we're going to rebuild them we should just do it for 1.11.

Rebuilding rdeps twice wont do anything (but if you push the rebuild with
old gdal to stable. I'm not sure release managers will accept) because
jessie packages won't change.

If I understand the problem correctly, the new version of gdal will
probably need to have a versionned Breaks to all packages that must
be upgraded with it. It is not enought that packages in sid are coherent,
they must also work (or Conflict/Break) with packages in stable.

  Regards,
    Vincent

> While I'm not entirely happy being unable to mark all affected packages
> as good in the tracker, I don't consider it a sufficient problem to add
> the alternative dependency to gdal 1.10.1 too.
> 
> If there will be a GDAL 1.11.3 after we get 1.11.2 in unstable and
> before GDAL 2.0, we can limit the affected packages to those depending
> on libgdal.so.1-1.11.2.
> 
> Kind Regards,
> 
> Bas
> 


-- 
Vincent Danjean       GPG key ID 0xD17897FA         vdanjean@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Message #82 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Vincent Danjean <vdanjean.ml@free.fr>, 756867@bugs.debian.org, Emilio Pozuelo Monfort <pochu@debian.org>, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Fri, 12 Jun 2015 12:17:27 +0200

On 06/12/2015 07:30 AM, Vincent Danjean wrote:
> Le 12/06/2015 01:06, Sebastiaan Couwenberg a écrit :
>> On 06/12/2015 12:26 AM, Emilio Pozuelo Monfort wrote:
>>> So let's say gdal 1.11 changed the ABI for some C++ symbols. Since the packages
>>> currently in sid don't have strict dependencies on the old ABI, the new library
>>> will be installed with the old packages, causing breakage.
>>
>> Rebuilding all affected packages should take care of that.
>>
>> Isn't the point of a transition to coordinate the upload of the new
>> library so that the old packages can be rebuilt with it soon after?
>>
>> The time between the upload of the new library and the rebuild of the
>> old packages should be minimal, leaving only a short window in which the
>> old packages may be broken.
> 
> This is true only if the new version of gdal cannot be installed with
> old (jessie) version packages using it.
>   I do not known anything about gdal. But remember you cannot assume that
> users will upgrade in one row from jessie to stretch/testing/unstable.

I don't believe partial upgrades are supported, so this seems a mostly
theoretical problem.

Actual users of gdal and its rdeps will want to be able to use those
rdeps so they will be motivated to not do a partial upgrade.

GDAL 1.11 is the first version that allows tracking of the rdeps that
use the C++ symbols, all earlier upgrades didn't care about that. Those
relied on the symbols version only for upgrades.

>>> What do you think about that situation? Should we add the dependency magic to
>>> 1.10, rebuild everything, and only then update to 1.11? Or do you think that
>>> case isn't a problem?
>>
>> I don't think it's worth the effort to rebuild all rdepds twice, if
>> we're going to rebuild them we should just do it for 1.11.
> 
> Rebuilding rdeps twice wont do anything (but if you push the rebuild with
> old gdal to stable. I'm not sure release managers will accept) because
> jessie packages won't change.
> 
> If I understand the problem correctly, the new version of gdal will
> probably need to have a versionned Breaks to all packages that must
> be upgraded with it. It is not enought that packages in sid are coherent,
> they must also work (or Conflict/Break) with packages in stable.

I definitely don't understand your concern. What is your actual real
world scenario, so I can better understand your point of view?

To my best understanding, distribution upgrades from jessie to stretch
will just work, with or without alternative dependency for packages
using C++ symbols, as they did before.

>> While I'm not entirely happy being unable to mark all affected packages
>> as good in the tracker, I don't consider it a sufficient problem to add
>> the alternative dependency to gdal 1.10.1 too.
>>
>> If there will be a GDAL 1.11.3 after we get 1.11.2 in unstable and
>> before GDAL 2.0, we can limit the affected packages to those depending
>> on libgdal.so.1-1.11.2.

I'm becoming increasingly disillusioned about getting GDAL 1.11 into
unstable and thereby gaining the spatialite_init_ex() support, the lack
of which is currently causing segfaults because only the deprecated
spatialite_init() method is used.

The gdal 1.11.2 package is Ubuntu from some time already, and they
didn't have these concerns. But that may be inherent to Ubuntu not being
as strict as Debian about these kind of issues.

I'd hate having to wait for GDAL 2.0 and the SONAME bump that should
introduce before getting a newer gdal in unstable.

Kind Regards,

Bas

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

Message #87 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Vincent Danjean <vdanjean.ml@free.fr>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>, 756867@bugs.debian.org, Emilio Pozuelo Monfort <pochu@debian.org>, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Fri, 12 Jun 2015 17:12:12 +0200

Le 12/06/2015 12:17, Sebastiaan Couwenberg a écrit :
> On 06/12/2015 07:30 AM, Vincent Danjean wrote:
>> Le 12/06/2015 01:06, Sebastiaan Couwenberg a écrit :
>>> On 06/12/2015 12:26 AM, Emilio Pozuelo Monfort wrote:
>>>> So let's say gdal 1.11 changed the ABI for some C++ symbols. Since the packages
>>>> currently in sid don't have strict dependencies on the old ABI, the new library
>>>> will be installed with the old packages, causing breakage.
>>>
>>> Rebuilding all affected packages should take care of that.
>>>
>>> Isn't the point of a transition to coordinate the upload of the new
>>> library so that the old packages can be rebuilt with it soon after?
>>>
>>> The time between the upload of the new library and the rebuild of the
>>> old packages should be minimal, leaving only a short window in which the
>>> old packages may be broken.
>>
>> This is true only if the new version of gdal cannot be installed with
>> old (jessie) version packages using it.
>>   I do not known anything about gdal. But remember you cannot assume that
>> users will upgrade in one row from jessie to stretch/testing/unstable.
> 
> I don't believe partial upgrades are supported, so this seems a mostly
> theoretical problem.

They are from stable to next stable. We already had the same discussion
several times with various software (the last one I remember being R).

> Actual users of gdal and its rdeps will want to be able to use those
> rdeps so they will be motivated to not do a partial upgrade.

My point is that the dependency system must ensure that packages
installed together, respecting package dependencies, from two consecutive
Debian release, work together.

> GDAL 1.11 is the first version that allows tracking of the rdeps that
> use the C++ symbols, all earlier upgrades didn't care about that. Those
> relied on the symbols version only for upgrades.

If the dependency system allows to have gdal 1.11 and old rdeps, then
they must work.
If old rdeps and gdal 1.11 does not work together, the dependency system
must reflect that (for example by adding versionned Breaks in new gdal
against old rdeps).

> I definitely don't understand your concern. What is your actual real
> world scenario, so I can better understand your point of view?

I hope the previous sentences (and the next one) explains my view.
If this is not the case, please tell me.

> To my best understanding, distribution upgrades from jessie to stretch
> will just work, with or without alternative dependency for packages
> using C++ symbols, as they did before.

You must also ensure that, on a jessie system,
"apt-get install -t stretch gdal" will not break any other package
(in particular gdal rdeps) [unless these breaks are declared as Breaks
or Conflicts or ... so that the "apt-get ..." command takes them into
account]

  Regards,
    Vincent

-- 
Vincent Danjean       GPG key ID 0xD17897FA         vdanjean@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Message #92 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Vincent Danjean <vdanjean.ml@free.fr>, 756867@bugs.debian.org, Emilio Pozuelo Monfort <pochu@debian.org>, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Fri, 12 Jun 2015 17:39:14 +0200

On 06/12/2015 05:12 PM, Vincent Danjean wrote:
> Le 12/06/2015 12:17, Sebastiaan Couwenberg a écrit :
>> On 06/12/2015 07:30 AM, Vincent Danjean wrote:
>>> Le 12/06/2015 01:06, Sebastiaan Couwenberg a écrit :
>>>> On 06/12/2015 12:26 AM, Emilio Pozuelo Monfort wrote:
>>>>> So let's say gdal 1.11 changed the ABI for some C++ symbols. Since the packages
>>>>> currently in sid don't have strict dependencies on the old ABI, the new library
>>>>> will be installed with the old packages, causing breakage.
>>>>
>>>> Rebuilding all affected packages should take care of that.
>>>>
>>>> Isn't the point of a transition to coordinate the upload of the new
>>>> library so that the old packages can be rebuilt with it soon after?
>>>>
>>>> The time between the upload of the new library and the rebuild of the
>>>> old packages should be minimal, leaving only a short window in which the
>>>> old packages may be broken.
>>>
>>> This is true only if the new version of gdal cannot be installed with
>>> old (jessie) version packages using it.
>>>   I do not known anything about gdal. But remember you cannot assume that
>>> users will upgrade in one row from jessie to stretch/testing/unstable.
>>
>> I don't believe partial upgrades are supported, so this seems a mostly
>> theoretical problem.
> 
> They are from stable to next stable. We already had the same discussion
> several times with various software (the last one I remember being R).
> 
>> Actual users of gdal and its rdeps will want to be able to use those
>> rdeps so they will be motivated to not do a partial upgrade.
> 
> My point is that the dependency system must ensure that packages
> installed together, respecting package dependencies, from two consecutive
> Debian release, work together.
> 
>> GDAL 1.11 is the first version that allows tracking of the rdeps that
>> use the C++ symbols, all earlier upgrades didn't care about that. Those
>> relied on the symbols version only for upgrades.
> 
> If the dependency system allows to have gdal 1.11 and old rdeps, then
> they must work.
> If old rdeps and gdal 1.11 does not work together, the dependency system
> must reflect that (for example by adding versionned Breaks in new gdal
> against old rdeps).
> 
>> I definitely don't understand your concern. What is your actual real
>> world scenario, so I can better understand your point of view?
> 
> I hope the previous sentences (and the next one) explains my view.
> If this is not the case, please tell me.
> 
>> To my best understanding, distribution upgrades from jessie to stretch
>> will just work, with or without alternative dependency for packages
>> using C++ symbols, as they did before.
> 
> You must also ensure that, on a jessie system,
> "apt-get install -t stretch gdal" will not break any other package
> (in particular gdal rdeps) [unless these breaks are declared as Breaks
> or Conflicts or ... so that the "apt-get ..." command takes them into
> account]

Thanks for the clarifications.

I agree that it's best to have the dependencies prevent users doing
foolish things like upgrading only gdal and expecting the rdeps to still
work.

Currently we don't know the versions of the rdeps that will break, so
these cannot be declared in the control file yet. I'm not sure how to
solve this (without adding the alternative dependency in the jessie
version of gdal).

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.

Kind Regards,

Bas

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

Message #97 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Josip Rodin <joy@debbugs.entuzijast.net>

To: Vincent Danjean <vdanjean.ml@free.fr>, 756867@bugs.debian.org

Cc: Sebastiaan Couwenberg <sebastic@xs4all.nl>, Emilio Pozuelo Monfort <pochu@debian.org>, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Fri, 12 Jun 2015 17:37:39 +0200

On Fri, Jun 12, 2015 at 12:17:27PM +0200, Sebastiaan Couwenberg wrote:
> The gdal 1.11.2 package is Ubuntu from some time already, and they
> didn't have these concerns. But that may be inherent to Ubuntu not being
> as strict as Debian about these kind of issues.
>
> I'd hate having to wait for GDAL 2.0 and the SONAME bump that should
> introduce before getting a newer gdal in unstable.

On Fri, Jun 12, 2015 at 05:12:12PM +0200, Vincent Danjean wrote:
> If the dependency system allows to have gdal 1.11 and old rdeps, then
> they must work.
> If old rdeps and gdal 1.11 does not work together, the dependency system
> must reflect that (for example by adding versionned Breaks in new gdal
> against old rdeps).

It just so happens I was on the receiving end of GDAL's ABI breakages with
an in-house dependent package, I feel I have to post this link here:

http://upstream.rosalinux.ru/versions/gdal.html

This library has apparently been consistently horrible about compatibility,
and it seems that it's high time that its SONAME, and consequently its
package names, started changing in order to avoid harming its users.

-- 
     2. That which causes joy or happiness.

Message #102 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>, 756867@bugs.debian.org

Cc: Vincent Danjean <vdanjean.ml@free.fr>, Emilio Pozuelo Monfort <pochu@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Sun, 14 Jun 2015 12:29:32 +1000

[Message part 1 (text/plain, inline)]

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.

Cheers,
Julien

[signature.asc (application/pgp-signature, inline)]

Message #107 received at 756867@bugs.debian.org (full text, mbox, reply):

From: "Rebecca N. Palmer" <rebecca_palmer@zoho.com>

To: 756867@bugs.debian.org, sebastic@xs4all.nl

Subject: Re: Bug#756867: transition: gdal

Date: Sun, 14 Jun 2015 08:14:52 +0100

> That probably
> means changing the libgdal binary package name

to e.g. libgdal1a; see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712688#10 and 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731261#30 for previous 
examples.

Message #112 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Julien Cristau <jcristau@debian.org>, 756867@bugs.debian.org

Cc: Vincent Danjean <vdanjean.ml@free.fr>, Emilio Pozuelo Monfort <pochu@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Sun, 14 Jun 2015 13:28:41 +0200

[Message part 1 (text/plain, inline)]

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, having the alternative dependency for the C++ symbols
doesn't have much benefit anymore. 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.

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.

Kind Regards,

Bas

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

[signature.asc (application/pgp-signature, attachment)]

Message #117 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>, Julien Cristau <jcristau@debian.org>, 756867@bugs.debian.org

Cc: Vincent Danjean <vdanjean.ml@free.fr>

Subject: Re: Bug#756867: transition: gdal

Date: Tue, 16 Jun 2015 01:21:52 +0200

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

Message #122 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Emilio Pozuelo Monfort <pochu@debian.org>, Julien Cristau <jcristau@debian.org>, 756867@bugs.debian.org

Cc: Vincent Danjean <vdanjean.ml@free.fr>

Subject: Re: Bug#756867: transition: gdal

Date: Wed, 17 Jun 2015 01:22:02 +0200

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

Message #127 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>, 756867@bugs.debian.org

Cc: Vincent Danjean <vdanjean.ml@free.fr>

Subject: Re: Bug#756867: transition: gdal

Date: Fri, 19 Jun 2015 13:21:19 +0200

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...

>>> 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.

> 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.

>>> 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.

Cheers,
Emilio

Message #132 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 756867@bugs.debian.org

Cc: Vincent Danjean <vdanjean.ml@free.fr>

Subject: Re: Bug#756867: transition: gdal

Date: Fri, 19 Jun 2015 14:40:04 +0200

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

Message #137 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Sebastiaan Couwenberg <sebastic@xs4all.nl>

Cc: Vincent Danjean <vdanjean.ml@free.fr>, 788533@bugs.debian.org

Subject: Re: Bug#756867: transition: gdal

Date: Fri, 19 Jun 2015 18:22:42 +0200

(Moving the discussion to #788533; #756867 bcc'ed)

On 19/06/15 14:40, Sebastiaan Couwenberg wrote:
> 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

I'm not sure there are buildds with more RAM. Note that the package failed in
the exact same way on kfreebsd-i386, which has 3GB of RAM + 4GB of swap. Since
all these arches are 32bits, more memory is probably not going to help.

Instead, perhaps you can make the build take less memory, e.g. by reducing the
optimizations (-O1?) or using some flags such as the linker's --no-keep-memory.

Cheers,
Emilio

Message #144 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 756867@bugs.debian.org, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Thu, 20 Aug 2015 12:59:03 +0200

On 19-06-15 14:40, Sebastiaan Couwenberg wrote:
> On 06/19/2015 01:21 PM, Emilio Pozuelo Monfort wrote:
>> On 17/06/15 01:22, Sebastiaan Couwenberg wrote:
>>> 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

To unblock the various transitions as mentioned in the geos transition
bugreport (#791045) that are waiting for a new gdal build in unstable,

I've prepared a new upload of gdal for experimental. It updates the C++
symbols for all architectures with GCC 5.

Because of an issue in the gdal configure checks, libkml support is
disabled due to the removed third party libraries in the new libkml.

I'll patch the gdal build to properly support the new libkml builds too,
after we get the transition moving to not have to update the symbols
again. Although these additions should be fine, as they won't require a
package rename.

As also mentioned in the geos issue, since geos is a build dependency of
gdal, I think it's better to update geos in unstable first and start the
gdal transition as part of that. We can probably limit the dependency
dance to untangle the spatialite->postgis->gdal->spatialite circular
dependency to a single pass. With that in mind I propose the following:

 * Upload geos (3.5.0-1) to unstable to start its transition (#791045)

 * Upload spatialite (4.3.0-2) to unstable, drops liblwgeom dependency

 * File RC bug on spatialite (4.3.0-2) about liblwgeom regression to
   prevent testing migration, and have the RC bug block the geos & gdal
   transition bugs (#791045, #756867).

 * Upload gdal (1.11.2+dfsg-1) to unstable to start its transition
    - built with spatialite (4.3.0-2) via versioned build dependency

 * BinNMU postgis with rebuilt gdal & spatialite in unstable

 * Upload spatialite (4.3.0-3) to unstable, reinstates liblwgeom
   dependency

 * BinNMU gdal with spatialite (4.3.0-3) in unstable

 * BinNMU postgis with rebuilt gdal & spatialite in unstable

The BinNMUs can also be substituted with an upload in which the
versioned build dependencies get bumped.

Kind Regards,

Bas

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

Message #149 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 756867@bugs.debian.org

Subject: Re: Bug#756867: transition: gdal

Date: Thu, 20 Aug 2015 23:24:18 +0200

On 20-08-15 12:59, Sebastiaan Couwenberg wrote:
> Because of an issue in the gdal configure checks, libkml support is
> disabled due to the removed third party libraries in the new libkml.
> 
> I'll patch the gdal build to properly support the new libkml builds too,
> after we get the transition moving to not have to update the symbols
> again. Although these additions should be fine, as they won't require a
> package rename.

Fixing the libkml issue in gdal turned out to be much less time
consuming than expected.

A couple of hours ago I uploaded libkml (1.3.0~rc0-3) to unstable which
adds the boost, expat & zlib dependencies to libkml-dev, it has not been
accepted into the archive at time of writing yet.

I've also prepared a new gdal upload for experimental that includes a
patch to add pkg-config support for the new libkml, and added the libkml
symbol to the common symbols file again.

Due to the requirement of the libkml (1.3.0~rc0-3) changes, I've not
uploaded gdal (1.11.2+dfsg-1~exp7) yet. I'll do that soon after the
libkml upload is accepted.

Kind Regards,

Bas

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

Message #156 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 756867@bugs.debian.org, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Fri, 21 Aug 2015 18:09:50 +0200

On 20-08-15 12:59, Sebastiaan Couwenberg wrote:
> To unblock the various transitions as mentioned in the geos transition
> bugreport (#791045) that are waiting for a new gdal build in unstable,
> 
> I've prepared a new upload of gdal for experimental. It updates the C++
> symbols for all architectures with GCC 5.
> 
> Because of an issue in the gdal configure checks, libkml support is
> disabled due to the removed third party libraries in the new libkml.

The libkml issue was fixed in gdal (1.11.2+dfsg-1~exp7) and that built
successfully on the release archs without further symbols changes.

I just uploaded gdal (1.11.2+dfsg-1) to unstable start unblock the
various transitions and kick off this transition.

We'll leave the geos transition (#791045) for later, postponing the
circular dependency between the shared rdeps.

Kind Regards,

Bas

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

Message #163 received at 756867@bugs.debian.org (full text, mbox, reply):

From: Sebastiaan Couwenberg <sebastic@xs4all.nl>

To: Emilio Pozuelo Monfort <pochu@debian.org>, 756867@bugs.debian.org, Julien Cristau <jcristau@debian.org>

Subject: Re: Bug#756867: transition: gdal

Date: Wed, 26 Aug 2015 13:26:40 +0200

All gdal rdeps maintained by the Debian GIS team have been rebuild for
the gdal transition except saga which is waiting for the libvigraimpex
transition (#793044).

rasterio (0.25.0-1) FTBFS on arm{el,hf}, but since the package hasn't
migrated to testing since its initial upload to unstable, this shouldn't
block the gdal transition.

The old vtk6 packages as still marked as bad in the transition tracker,
but the new ones are rebuilt for the gdal transition.

This leaves the following packages still in need of a rebuild:

 gazebo   (5.0.1+dfsg-2.1) [BD-Uninstallable]
 node-srs (0.4.8+dfsg-1)
 sumo     (0.23.0+dfsg1-2)
 xastir   (2.0.6-4)

Kind Regards,

Bas

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

Message #168 received at 756867-done@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: Bas Couwenberg <sebastic@xs4all.nl>, 756867-done@bugs.debian.org

Subject: Re: Bug#756867: transition: gdal

Date: Sun, 6 Sep 2015 11:01:11 +0200

[Message part 1 (text/plain, inline)]

On Sat, Aug  2, 2014 at 20:41:59 +0200, Bas Couwenberg wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> The Debian GIS team would like to get GDAL 1.11.0 into jessie before the
> freeze.
> 
> Currently GDAL 1.10.1 is unstable and jessie, and GDAL 1.11.0 is in
> experimental.
> 
> Updating GDAL from 1.10.1 to 1.11.0 involves a SONAME bump from
> libgdal.so.1.17.1 to libgdal.so.1.18.0.
> 
AFAICT this is now done.

Cheers,
Julien

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.