Re: library-related policy question
Steve Langasek <firstname.lastname@example.org> writes:
>> 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.
ffmpeg has "installed" headers and headers that are just in the ffmpeg
source tree. since mplayer ships its own copy of ffmpeg, it can include
these private headers in addition to the jheaders that are supposed to
be installed in the package.
yes, mplayer upstream is not supposed to use these headers, but they do
it anyways. this has historic reasons, and I have the impression they
slowly try to get away from this as ffmpeg matures more and more.
Reinhard Tartler, KeyID 945348A4