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 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5580af9a.2080...@xs4all.nl
