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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
