On 21 September 2015 at 08:38, Simon McVittie wrote: | Source: quantlib | Version: 1.6.2-1 | Severity: serious | Justification: ABI break since stable for libquantlib0 | Tags: sid stretch | User: debian-...@lists.debian.org | Usertags: libstdc++-cxx11 | | Background[1]: libstdc++6 introduces a new ABI to conform to the | C++11 standard, but keeps the old ABI to not break existing binaries. | Packages which are built with g++-5 from experimental (not the one | from testing/unstable) are using the new ABI. Libraries built from | this source package export some of the new __cxx11 or B5cxx11 symbols, | dropping other symbols. If these symbols are part of the API of | the library, then this rebuild with g++-5 will trigger a transition | for the library. | | In the case of quantlib, <ql/currency.hpp> is one example of public API | changing its ABI in this way, so a transition does appear to | be needed. The transition normally consists of renaming the affected library | packages, adding a v5 suffix (libquantlib0v5). The SONAME should not be | changed when doing this. | | If an upgrade to a new upstream SONAME is already planned, and that | SONAME has never been available in Debian compiled with g++-4, then an | alternative way to carry out the transition would be to bump the | SONAME. However, the libstdc++ transition has been going on for nearly | 2 months already, and anything that makes it take longer is bad for Debian, | so introducing new upstream code is not recommended at this stage. | | These follow-up transitions for libstdc++ are not going through exactly | the normal transition procedure, because many entangled transitions are | going on at the same time, and the usual ordered transition procedure | does not scale that far. When all the C++ libraries on which this library | depends have started their transitions in unstable if required, this | library should do the same, closing this bug; the release team will deal | with binNMUs as needed. | | Looking at the build-dependencies of quantlib, boost has already had | its transition, so I believe quantlib is now ready to be renamed.
I was thinking I could get away with _not_ renaming. If you'd rather that I renamed, I can do that today. | | quantlib does appear to have had an upload built with g++-5 already. Correct. As do the _two_ depedent packages both of which I maintain: - quantlib-python (same upstream, SWIG bindings) - r-cran-rquantlib (I am upstream) So they are all compiled with g++-5.4, I just didn't switch to libquantlib0v5 libquantlib1 (alternate, as I never renamed ...) So you say I should? Dirk | Please note that this rebuild is *not* sufficient to prevent broken | upgrades: for example, during an upgrade from jessie to stretch, if a | user upgrades quantlib to the stretch version while keeping jessie's | quantlib-swig or rquantlib, then quantlib-swig or rquantlib will | fail to link at runtime with undefined symbols. Preventing broken | situations like that is why the renames are necessary. | | The package might be NMU'd if there is no maintainer response. The | release team have declared a 2 day NMU delay[2] for packages involved | in the libstdc++ transition, in order to get unstable back to a usable | state in a finite time. | | Regards, | S | | [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition | [2] https://lists.debian.org/debian-devel-announce/2015/08/msg00000.html -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
