Bug#799649: stk: ABI transition needed for libstdc++ v5

[Felipe Sateler]

Hi,

On 21 September 2015 at 05:21, Simon McVittie <smcv at debian.org> wrote:
> Source: stk
> Version: 4.4.4-5
> Severity: serious
> Justification: ABI break since stable when rebuilt
> Tags: sid stretch
> User: debian-gcc at 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 stk, there's a lot of std::string use in include/,
> so a transition does appear to be needed. The transition normally
> consists of renaming the affected library packages, replacing the
> c2a suffix from a similar previous transition with a v5 suffix
> (libstk0v5). 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 stk, rtaudio and rtmidi have
> already had their renames, so I believe stk is now ready to be renamed.
>
> 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.

Please go ahead. I do not know when I will have time to look at this,
so do not wait on me.


-- 

Saludos,
Felipe Sateler