On Mon, Jun 10, 2024 at 8:19 AM Shengjing Zhu <[email protected]> wrote:
> On Mon, Jun 10, 2024 at 6:45 PM Reinhard Tartler <[email protected]> > wrote: > > On Mon, Jun 10, 2024 at 2:48 AM Shengjing Zhu <[email protected]> wrote: > >> >> Though removing src:golang-github-golang-protobuf-1-3 probably will > not be easy. > >> > > >> > Can you please elaborate on where you see the difficulties? > >> > >> Only pb.go files generated by protoc-gen-go-1-3 are compatible with > >> gogo protobuf. That's where the protobuf transition stuck... > > > > Well, I suppose that means either protoc-gen-go-1-3 or protoc-gen-gogo > (from gogoprotobuf). > > > > Can you please point out examples of packages with "pb.go" files that > are generated with protoc-gen-go-1-3 and then used with gogo protobuf? > > > > Hmm, I thought you already saw that. You mentioned > https://github.com/containerd/ttrpc/issues/62#issuecomment-686768932 > in another thread. > This is caused by using gogo protobuf (at runtime) with pb.go files > (from golang-google-genproto-dev) generated by protoc-gen-go-1-5 (or > newer). > 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 [email protected] and after convincing myself that both internal testsuites pass, uploaded it to experimental. I've tested builds of containerd built against [email protected] 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? [1] https://github.com/containerd/containerd/releases/tag/v1.7.0 Other than ttrpc/containerd, are there any other packages in a similar situation that need similar untangling? -- regards, Reinhard
