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

Re: library-related policy question



> On Sun, Sep  6, 2009 at 12:50:59 +0200, Emilio Pozuelo Monfort wrote:
> > Nikita V. Youshchenko wrote:
> > > Hi
> > >
> > > Is there an statement in Debian Policy that explicitly requires
> > > higher version of a shared library package to be
> > > backwards-binary-compatible with previous versions of the same
> > > package?
> > >
> > > I mean, is a situation when after library package upgrade local
> > > binaries stops working because of missing symbols, by definition an
> > > RC bug against library package? Or is depends on particular
> > > situation?
> >
> > Yes, it's an RC bug. If you break the API and/or ABI, you need to
> > change the package name and the SONAME.
>
> AFAIK the rule is "if you break ABI, you MUST change the package name
> and SHOULD change the SONAME".
>
> Policy already has "The run-time shared library needs to be placed in a
> package whose name changes whenever the shared object version changes"
> (with the assumption that the SONAME changes when ABI breaks) in section
> 8.1.

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.

To be particular: this is about libavformat52 and mplayer.

mplayer from debian sid, executed against libavformat52 sid, works.

mplayer from debian sid, executed against libavformat52 from 
debian-multimedia, fails with 'mplayer: symbol lookup error: mplayer: 
undefined symbol: codec_wav_tags'.

We've discussed that with Christian Marillat (debian-multimedia 
maintainer), that resulted into upstream bug report at 
http://roundup.ffmpeg.org/roundup/ffmpeg/issue1352, but upstream rejected 
the issue.

As of today, debian does not contain this bug, because ffmpeg with this 
brakage happened not to be uploaded yet to debian. However, once it is, 
the bug will be in debian, and will have to be handled somehow.

Nikita


Reply to: