On Tue, Dec 09, 2008 at 04:06:46PM +0000, Neil Williams wrote: > On Tue, 9 Dec 2008 22:18:01 +0900 > "Paul Wise" <[EMAIL PROTECTED]> wrote: > > > On Tue, Dec 9, 2008 at 9:40 PM, Andy Hawkins <[EMAIL PROTECTED]> > > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
