Re: how to best handle this library update?
On 2010-09-06, sean finney <seanius@debian.org> wrote:
> 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? =20
>
> 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.
How will that make it work if I have a c++ app installed, with a
dependency of libxmlrpc-c3, and then I upgrade just libxmlrpc-c3 to a
newer version without the c++ things?
> 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.
4) put one library in one package that follows the naming scheme of
libfoo.so.X goes in libfooX, and make sure you don't reuse the
libxmlrpc-c3 package name, and be done with it once and for all.
5) do (4) in several steps. With current unstable sources, do the split,
but keep the libxmlrpc-c3 packgae name temporarily for migration
purposes. Wait for this to migrate to testing. Now get all of the
involved packages binNMU'ed. let them migrate to testing. Upload a new
edition of current source dropping libxmlrpc-c3 temporary package. wait
for testing migration. Upload new version of libxmlrpc-c3 with the abi
changes (and package name changes) and get the involved packages
binNMU'ed.
Looking at the involved number of packages, 5) sounds overkill.
1) is wrong. 2 and 3 are both hacks. That leaves the real solution, 4).
/Sune
Reply to: