"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. Usually this is more hassle than it's worth, but diverging from upstream on SONAME can also be an annoying long-term maintenance problem. The more central the library (and hence the larger the transition if it changes SONAME), the more it's worth putting some effort into avoiding changing the SONAME. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
