Bug#797867: libzypp: ABI transition needed for libstdc++ v5
Control: close -1 Control: fixed -1 17.3.1-1 Hi, On Thu, 3 Sep 2015 08:30:01 +0100 Simon McVittie wrote: > Source: libzypp > Version: 15.3.0-1 > Severity: serious > Justification: breaks ABI without a package rename > 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 libzypp, std::string appears in major classes such as > Pathname, so it seems very likely that a transition is needed. The > transition normally consists of renaming the affected library packages, > adding a v5 suffix. The SONAME should not be changed when doing this. > However, libzypp is not packaged according to Policy §8.1 and does > not generate correct dependencies (I'll file a separate bug), > so a versioned Breaks on zypper will probably be needed as well. > > 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. Please avoid doing this unless the new upstream version > is very low-risk. > > 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 libzypp, the C++ libraries > are Boost, which has had its rename already (while moving from 1.55 > to 1.58), and libproxy, which only has a C ABI so does not need a > rename; so this sub-transition is ready to start. > > 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/msg0.html This bug should be resolved with latest upload of libzypp 17.3.1-1 to Debian unstable. Unfortunately, I had the wrong bug closure in debian/changelog and this bug did not get closed with the upload. Thus closing manually... (with a post-upload fix in debian/changelog). Mike
Bug#797867: libzypp: ABI transition needed for libstdc++ v5
On 2015-10-30 15:56:38 [+0100], Emilio Pozuelo Monfort wrote: > This is a friendly ping wrt the libstdc++ ABI transition. Your package is > listed > as needing a transition but has seen no action. It'd be good to get things > going > so we can finish the transition soon. Mike, this package didn't complete the libstdc++ v5 transition. From #797869 it reads like it does not provide a stable ABI/symbols. Upstream has a newer version sitting (15.22.0). Would you mind to remove it from unstable until the two RC bugs are resolved? libzypp also depends on libssl1.0.0 which I am trying to decruft. > Cheers, > Emilio Sebastian
Bug#797867: libzypp: ABI transition needed for libstdc++ v5
This is a friendly ping wrt the libstdc++ ABI transition. Your package is listed as needing a transition but has seen no action. It'd be good to get things going so we can finish the transition soon. Cheers, Emilio
Bug#797867: libzypp: ABI transition needed for libstdc++ v5
Source: libzypp Version: 15.3.0-1 Severity: serious Justification: breaks ABI without a package rename 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 libzypp, std::string appears in major classes such as Pathname, so it seems very likely that a transition is needed. The transition normally consists of renaming the affected library packages, adding a v5 suffix. The SONAME should not be changed when doing this. However, libzypp is not packaged according to Policy §8.1 and does not generate correct dependencies (I'll file a separate bug), so a versioned Breaks on zypper will probably be needed as well. 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. Please avoid doing this unless the new upstream version is very low-risk. 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 libzypp, the C++ libraries are Boost, which has had its rename already (while moving from 1.55 to 1.58), and libproxy, which only has a C ABI so does not need a rename; so this sub-transition is ready to start. 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/msg0.html
