Re: Listing dependencies with specific versions
On Tue, Dec 09, 2008 at 04:06:46PM +0000, Neil Williams wrote:
> On Tue, 9 Dec 2008 22:18:01 +0900
> "Paul Wise" <pabs@debian.org> wrote:
>
> > On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins <andy@gently.org.uk>
> > wrote:
> >
> > > New symbols. It specifically has support for embedding images into
> > > the FLAC file. This was introduced in 1.2.
> >
> > Looks like you just found an RC bug in libflac++6 - includes new
> > symbols in version 1.2.1-1 according to mole but the shlibs does not
> > depend on that version:
>
> That is not a bug - the package building against it merely has to
> require that version.
Sure, if the package that is building needs those symbols. But what about
other packages that *don't* necessarily need those symbols, but get built
against the newer version of the library anyway? Those symbols can end up
in the built binary, but unless dpkg-shlibdeps happens to know that symbols
have been added, it won't know to version the library dependency and all
hell breaks loose.
The solution: shlibs files, which list the last package version in which a
new symbol was added to the library, so that the packaging system can make
sure that that newer version is available to packages that need the extra
symbols.
> The bug only arises if symbols are removed or function prototypes are
> changed in existing symbols.
Not quite. If you remove symbols or change the type of a symbol, you need
to bump the SONAME because that's the only piece of information that the
dynamic linker has to be able to determine if a *newer* library will or
won't work with a particular binary.
If you add symbols, you don't need to bump the SONAME because the library is
still backwards-compatible -- the SONAME effectively defines a "base ABI"
that will continue to work into the future, and when that no longer applies,
*then* the SONAME is bumped.
> If it was, we'd be on libglib.so.7787.0.0 by now.
*cough*
/usr/lib/libglib-2.0.so.0.1600.6
Not quite, but close...
> > Hopefully more libraries will adopt the new dpkg symbols stuff so that
> > this can be detected and fixed more often.
>
> The fix is only necessary if the symbol has CHANGED - added symbols can
> be managed perfectly well without a SONAME bump.
Yes, you are perfectly correct about this. But we're not referring to a
SONAME bump, we're talking about putting correct information in the shlibs
file regarding new symbols.
- Matt
Reply to: