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