Re: How to prevent a library transition
Frank Kuester wrote:
> As far as I can see, in this case all other packages would continue
> using libkpathsea-dev (corresponding to libkpathsea3) for building, and
> continue to depend on libkpathsea3, which in turn would continue to be
> available. Only the tetex-bin deb itself would depend on libkpathsea4.
>
> Thanks to the name change from libkpathsea-dev (soname version 3) to
> libkpathsea4-dev, there would be no library transition at all. At some
> later date, we could trigger the transition, when library transitions
> are allowed again.
So the plan is to make sure that there are no other shared libraries linked to
libkpathsea4 at all; only the executables from tetex-bin?
That should work, as long as you make sure that nobody else at all links
against libkpathsea4. You'll want to mail every maintainer of a package
depending on libkpathsea-dev to tell them *not* to update their packages to
libkpathsea4 until you give the go-ahead. And then you'll have to mail them
all again when you do give the go-ahead!
I notice that the symbols in libkpathsea3 are *not* versioned. I'm guessing
that the symbols in libkpathsea4 aren't either (if they are, ignore the
following). Accordingly, when the transition happens, you'll have to make
sure nothing is linked (even indirectly) to both versions. This actually
looks like it won't be a problem; I don't think there are any programs which
link kpathsea through two different dependency chains (in fact, I only found
one library which links to kpathsea: vflib3).
--
Nathanael Nerode <neroden@twcny.rr.com>
Make sure your vote will count.
http://www.verifiedvoting.org/
Reply to: