On Tue, 9 Dec 2008 16:06:46 +0000 Neil Williams <codehelp@debian.org> wrote: > The bug only arises if symbols are removed or function prototypes are > changed in existing symbols. > > > http://qa.debian.org/cgi-bin/mole/seedsymbols/.raw/seedsymbols/libflac++6_i386 > > Then a new line gets added for a symbol that only occurs in that > version. > > > Please file a bug about this. > > Please don't - it is not a bug. > > If it was, we'd be on libglib.so.7787.0.0 by now. See the list here: http://library.gnome.org/devel/glib/unstable/ Index of new symbols in 2.2 Index of new symbols in 2.4 Index of new symbols in 2.6 Index of new symbols in 2.8 Index of new symbols in 2.10 Index of new symbols in 2.12 Index of new symbols in 2.14 Index of new symbols in 2.16 Index of new symbols in 2.18 Index of new symbols in 2.20 Adding a new function (or several hundred new functions) has absolutely ZERO impact on the SONAME as long as the new functions do not overlap existing functions, change existing functions or require any changes elsewhere in the library that remove or modify existing symbols. Cyril, we need to sort this out for that RC bug that doesn't exist but which you raised the severity - adding a new symbol is NOT a bug, as long as it is done properly (as above). It is up to the package using the library to build-depend on the right version and use a strict dependency on that version or later that supercedes the plain dependency. i.e. exactly what I recommended for this package. Specify the strict version ahead of shlib:Depends and dpkg-shlibdeps does the right thing. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpswHJl8Xznw.pgp
Description: PGP signature