Control: owner -1 ! Hi,
First thing first. Protocol Buffers is a data interchange format used by several projects and C++ based. Language bindings are available, but not all of those come from upstream, Google Inc. It also has an RPC library and framework called gRPC with language bindings on its own. Rebuilding tests are in progress. But the following things are crucial. protobuf now builds ruby-google-protobuf which was built from src:ruby-google-protobuf previously. The mentioned dependency, grpc now includes the ruby-grpc and ruby-grpc-tools binaries. Previously these were built from src:ruby-grpc. Conflicts and replaces are in place of course. 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. Praveen, as I saw you even talked to the Security Team about backporting protobuf and grpc packages to Stretch for GitLab issues[4]. Please do so with caution about protobuf-c for the reasons mentioned above. In the future pretty please at least Cc me for transition requests for packages that I maintain. It's much harder to learn that it's already filed by someone else who may not know all the consequences. Thanks, Laszlo/GCS [1] https://github.com/cloudwu/pbc [2] https://jpa.kapsi.fi/nanopb/ [3] https://squidfunk.github.io/protobluff/ [4] https://salsa.debian.org/ruby-team/gitlab/wikis/stretch-backports
