the package in question is xmlrpc-c, which provides among other things libxmlrpc-c3. this package contains runtime libraries for c and c++ applications. it has a fairly small (6, from a quick look) set of reverse dependencies.
in the version in testing/unstable, these c/c++ libraries shared the
same soname, though in hindsight this seems to have been more coincidence
than design intention. in more recent versions of the upstream software,
the c++ abi has been broken and the soname has correctly been incremented
to refelct this. however the soname in the c libraries remains the same
as the abi has not been broken there.
so my question is, what is the most sane way to deal with this in the
packaging, esp. with respect to their reverse dependencies?
if it were also an abi break for the c libraries this would have been a bit
easier as i could have split both libraries into new packages and there
wouldn't be any breakage of the rdeps since the old library packages
would remain in place. but since this isn't the case, the rdeps would
see their needed libraries (the c++, old abi) vanish.
i have the following ideas:
1) split out the c++ libraries, make the c++ library conflict with the older
version of libxmlrpc-c3 (conflicting files) make the -dev package
depend on both libraries, and hope that a half dozen binNMU's fix the
problem quickly enough.
2) do (1) but also fake an abi break in the c libraries, renaming this
package as well (i could leave the SONAME the same though, right?
allowing the old libraries to stay while the transition takes place.
3) do no splitting for now, but rename the package to reflect the SONAME
change (i.e. libxmlrpc-c6) and save the splitting for some other time.
other ideas or comments of the above would be welcome...
sean
--
signature.asc
Description: Digital signature
