On Sun, Sep 06, 2009 at 11:26:20AM -0700, Russ Allbery wrote: > "Nikita V. Youshchenko" <yo...@debian.org> writes:
> > This does not help in a corner case. > > Issue I am looking at is: > > - a library used to export a symbol, it was visible in objdump -T output, > > - at some point, upstream decides that this symbol should be removed, > > claiming that "it was not ever included in any public APIs". > > - but this results into binary stop working. > We have done this in the past in Debian without changing the SONAME in > places where compatibility of SONAME with other distributions is > important. Specifically, libkrb53 removed several private symbols and we > didn't change the SONAME. *However*, if you're thinking about doing that, > you have to both be quite sure that the number of packages using that > symbol is very limited and rare *and* coordinate that change with all of > those packages, which will probably mean adding Breaks to the new version > of the shared library. And if the symbols in question were exported in a header (else how did mplayer come to depend on them?), it can be very difficult to be sure you know the complete set of reverse-dependencies. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature