Re: library-related policy question
"Nikita V. Youshchenko" <yoush@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: