On Fri, 6 Jul 2018 10:55:03 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= <gcs@debian.org> wrote: > The most problematic point is the protobuf-c dependency package. It > was developed (and packaged) by one of us (an other DD), Robert S. > Edmonds. It is the most complete C language implementation of Protocol > Buffers. While it has a newer upstream release in Git than the > packaged version, it's still not compatible with protobuf 3.6.0.1 > which is in experimental. > Main reason is that scoped_array (a class template to store pointers > to a dynamically allocated array) is removed from newer protobuf > releases, still protobuf-c still would like to use it. While Boost has > a similar (same?) scoped_array implementation since its 1.49 version, > I highly doubt protobuf-c should be altered to use that. As I can't > reach Robert for about nine months and I don't see any life sign from > him either, protobuf-c definitely needs a new upstream maintainer with > internal protobuf knowledge. > > Of course, several other C implementation of protobuf exist. > PBC[1] seems to be dead for more than a year now and does _not_ have a > code generator. > Nanopb[2] is a trim down version for 32 bits and microcontrollers only. > protobluff[3] seems to be the most viable alternative. It's modular, > seems to be in development and integrates with the upstream code > generator. > None of these are packaged as I know. > > But why is all the fuzz you may ask. The protobuf-c library is used by > several big / important projects. Like Knot DNS (a high-performance > DNS server, knot), CRIU (Checkpoint/Restore In Userspace, criu) and > PostGIS (geographic objects support for PostgreSQL, postgis) - > maintained by people like Ondřej Surý and Carnil (Salvatore > Bonaccorso), ones that I bow before them for their knowledge. These > packages and others would break with starting the protobuf transition > without protobuf-c being updated. Porting these to protobluff might be > an even bigger task. László, What do you think about providing protobuf3.0 in parallel to updating protobuf to 3.6? That way we can move ahead with gitlab and provide more time for either updating protobuf-c or porting packages to protobluff. We can drop protobuf3.0 when protobuf-c issue is resolved. Thanks Praveen
Attachment:
signature.asc
Description: OpenPGP digital signature