[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

how to best handle this library update?

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...



Attachment: signature.asc
Description: Digital signature

Reply to: