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

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.

Reply to: