Thanks for the reminder.
I've started looking at ttrpc. This is an interesting package. Basically, they have implemented a "lightweight" grpc implementation, by replacing the framing mechanism to make it use less memory. That's cool. Their use of gogoproto is certainly problematic. Also, they provide a code generator that does not appear to be used by any package in Debian. I see no good coming from keeping this package in Debian, so I took the liberty of dropping that binary package. Please do let me know of any breakages, adding it back is easy and quick at this point.
Luckily, it turns out that ttrpc upstream have phased out gogoproto in their newest upstream. I've testbuilt the current containerd package in unstable against ttrpc@v1.2.4 and after convincing myself that both internal testsuites pass, uploaded it to experimental. I've tested builds of containerd built against ttrpc@v1.2.4 in experimental and tried to compile
docker.io against it. While that build succeeded, building
docker.io against that build indeed produces compilation errors:
#
github.com/containerd/containerd/events/exchange../../containerd/containerd/events/exchange/exchange.go:97:17: cannot use typeurl.MarshalAny(event) (value of type typeurl.Any) as *types.Any value in assignment: need type assertion
#
github.com/containerd/containerd/runtime/v1/shim../../containerd/containerd/runtime/v1/shim/service.go:415:18: cannot use a (variable of type typeurl.Any) as *"
github.com/gogo/protobuf/types".Any value in assignment: need type assertion
make[1]: *** [debian/rules:114: override_dh_auto_build] Error 1
I note that containerd 1.7 [1] has a change that replaces its use of gogoproto with newer versions of protobuf. I guess we should therefore try to update the containerd package to that version, which would (very likely) be required by more modern versions of docker anyways. Anything I should keep in mind before attempting this stunt?