Bumping the soname is part of our release process, since C++ ABI compatibility is practically impossible to maintain. Unfortunately, if SVN is to be believed, it appears that somehow this didn't happen with the 2.2.0 release. And here I thought I had finally done a release without screwing anything up!
I guess I will do a 2.2.0a which does nothing but fix this. I'd like to avoid changing the last digit there because it would create a bunch of new ways that I could screw up. On Wed, Nov 18, 2009 at 3:55 PM, Robert Edmonds <edmo...@debian.org> wrote: > [ kenton varda, upstream release engineer for protobuf, added to Cc. ] > > Dirk Eddelbuettel wrote: > > I am not sure what the best way forward is. Given that mumble is the only > > user of protobuf, could you just rebuild based on the protobuf? That is > > probably quicker than a new upload, NEW queue, required rebuild, ... and > > avoids all hazzles regarding soname conflicts if we move to 5 now and > Google > > later claims 5. > > since the changes from 2.1.0 to 2.2.0 have demonstrably broken ABI > compatibility, the SONAME really should be bumped, regardless of NEW > delays, etc. because it is the correct thing to do, rather than breaking > unrelated software. ideally it should be coordinated with upstream so > that we don't break binary compatibility with other linux distributions > (to the extent that this is possible with the C++ ABI, which i am not > especially familiar with). > > kenton, is it possible to make a 2.2.1 release with just a SONAME bump? > see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556563 for the > relevant justification: > > m...@exez:~$ mumble > mumble: Symbol `_ZTIN6google8protobuf7MessageE' has different size in > shared object, consider re-linking > mumble: symbol lookup error: mumble: undefined symbol: > _ZN6google8protobuf14MessageFactory29InternalRegisterGeneratedFileEPKcPFvvE > > i've also noticed that these changes break the protobuf-c package (for > which i am the debian maintainer): > > edmo...@chase{0}:~$ protoc-c > protoc-c: symbol lookup error: /usr/lib/libprotoc.so.4: undefined > symbol: _ZN6google8protobuf8internal10WireFormat21kWireTypeForFieldTypeE > > i think protobuf-c and mumble are the only two reverse dependencies of > protobuf, and they're both broken by the 2.2.0-0.1 upload. > > the protobuf debian package unfortunately lacks .symbols files for > libprotocN and libprotobufN, which would have caught this problem. > when .symbols files are in use, the package build should fail if there > are any symbol insertions or deletions. > > i've rebuilt the debian protobuf 2.1.0-1 package, adding symbol files, > and then used the result to rebuild the 2.2.0-0.1 package, which reveals > that there are quite a few missing symbols in 2.2.0: > > edmo...@chase{0}:~/debian/protobuf/symbols/protobuf-2.2.0/debian$ grep > _ZN6google8protobuf14MessageFactory29InternalRegisterGeneratedFileEPKcPFvvE > *.symbols > libprotobuf4.symbols:#MISSING: 2.2.0# > _zn6google8protobuf14messagefactory29internalregistergeneratedfileepkcpf...@base2.1.0 > > (the missing symbol that broke mumble.) > > edmo...@chase{0}:~/debian/protobuf/symbols/protobuf-2.2.0/debian$ grep > MISSING *.symbols | wc -l > 311 > > (310 other symbols are missing as well.) > > i've attached the revelant diff.gz's. > > btw, 2.2.0 introduced a new 'libprotobuf-lite' library which should be > split out of the libprotobuf binary package, since (i gather) the idea > is to have a lite version of the library which doesn't require the full > heft of libprotobuf. > > -- > Robert Edmonds > edmo...@debian.org > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAksEiVcACgkQdp+/SHMBQJFXTQCgi8udEma1ccxxzHxMw4RPcjT/ > 7e8An3+4He41DprUK0BefB/hdWLncwag > =3+hv > -----END PGP SIGNATURE----- > >
