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 <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
