Bug#901015: transition: protobuf
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
Reply to: