On 21/09/15 12:51, Dirk Eddelbuettel wrote:
> | Yes, you should rename to libquantlib0v5 and ask the release team to
>
> I'd prefer libquantlib1. Any reason not to?
Changing the SONAME for this transition would be misleading unless the
SONAME is already Debian-specific (in which case it would be
libfoo.so.0debian1 or something), because the ABI depends on whether it
was compiled with g++-4 or g++-5, and not on anything about the actual
source code.
Your current source code compiled with g++-5 has the old SONAME but the
new ABI; source code with a new SONAME compiled with g++-4 would have
the new SONAME but the old ABI.
The solution is to change something that is part of the Debian
packaging: the package name.
> | binNMU the bindings against it, unless you have another way to ensure
>
> I fail to understand. The two packages both have sufficient Build-Depends as
> eg here for quantlib-python
>
> Build-Depends: debhelper (>= 7.0.0), python, python-all-dev (>= 2.6.6-3), \
> libquantlib0-dev (>= 1.6.2), gcc (>= 4:5.2), g++ (>= 4:5.2), \
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> libboost-dev (>= 1.34.0), libboost-test-dev (>= 1.34.0)
>
> resulting in corresponding versioned Depends.
That is *normally* sufficient to do the right thing, but is not
sufficient to prevent breakage in this ABI transition, because the
libstdc++ change makes newer versions incompatible with older versions
(if it didn't, we wouldn't have needed hundreds of transitions involving
thousands of packages).
Specifically, the versions of the bindings currently in jessie depend on
a version that is satisfied by the version of quantlib in stretch - but
the quantlib binary in stretch is not compatible with those binding
binaries, because compilation with a newer g++ caused it to break its ABI.
> | that broken combinations of packages cannot be installed (including
> | during the upgrade from jessie-as-oldstable to stretch-as-stable after
> | stretch is released).
>
> I don't see how using the package manager.
If you do the v5 rename as suggested, it prevents the installation of a
broken combination of packages; libquantlib0v5 should conflict/replace
libquantlib0 (because they conflict over the path libquantlib.so.0), old
bindings depend on libquantlib0, and new bindings depend on
libquantlib0v5. The combination of those forces quantlib and all the
installed bindings to be from the same "world".
The wider transition of which this is a part has been going on for
nearly 2 months, and is quite well-understood. I'm sorry it took so long
for the mass-bug-filing to reach the last few packages with an ABI break
and known rdeps (such as quantlib), but everyone involved is getting
quite burned-out at this point.
S
