Yes they are not compatible. But for the packaging, there are no
conflicts around gogoprotobuf packages. You probably misread
golang-goprotobuf-dev as golang-gogoprotobuf-dev. (These names are
very similar...). golang-goprotobuf-dev is a transitional package
which ties the runtime dev package and the code generator together.
> - It seems to me that we probably want to move packages away from src:golang-gogoprotobuf as much as possible, in particular because of the interoperability concerns. Is that agreeable?
>
Yes. This package is dead, and we also should convince upstream to
move away from it.
> - It also seems to me that we probably want to avoid having both golang-github-golang-protobuf-1-3 and golang-github-golang-protobuf-1-5 at the same time. Both implement APIv1, and as such should be source-code compatible. We currently seem to have 19 packages build-depending on golang-github-golang-protobuf-1-3-dev. Can we lift-and-shift all of them in one transition to @v1.5?
>
I think so. The runtime library golang-github-golang-protobuf-1-5-dev
should be compatible with golang-github-golang-protobuf-1-3-dev.
Current approach of listing them as alternative dependency seems to be
working more gracefully. I probably should not introduce
golang-github-golang-protobuf-1-3-dev at first, but only keep the
protoc-gen-go-1-3 (the pb.go generator) around.
> - As for packaging docker 2.4 (cf. #1033839, which spun off this conversation), which of the four library implementations above should it be linking against? -- We can savely rule out gogoprotobuf (it's deprecated), and I guess google-protobuf as well, because I don't think all dependencies have moved to the APIv2. That leaves two options: golang-protobuf @v1.3 and @v1.5. Given the compatibility concerns above, I guess @v1.5 is the better choice. That means that at least the 'notary' package needs to be updated (as Arnaud points separately) to pick up protobuf v1.5.
>
I think the notary code doesn't need to change. Just switching the
golang-github-golang-protobuf-1-*-dev in Depends could work. As the
1.5 should be compatible with 1.3.
> - Currently, packages that use grpc (that is, build-depend on golang-google-grpc-dev or protoc-gen-go-grpc), contain code that is generated with golang/protobuf @v1.5. Wouldn't we expect applications that use grpc to (possibly silently) break when linked against any other library than protobuf @v1.5? Would it help to reflect this in package relationships (i.e., add appropriate Conflicts or Build-Conflicts relationships)?
>
protoc-gen-go-grpc is a new binary package, which is not used by any
package yet.
In theory, if the pb.go files are generated by protoc-gen-go-1-5 or
protoc-gen-go (the generator without version suffix is from
src:golang-google-protobuf), and the application still uses
golang-github-gogo-protobuf-dev as runtime library, than it will
break.
>From my observation for some upstream projects over these years, I
think the breakage only happens when the pb.go files from
golang-google-genproto-dev are generated by the new generators.
For example, the containerd project pins the version at
https://github.com/containerd/containerd/blob/74a86c30b3fcbb06802f4e3d95f49d0a127d4298/go.mod#L143
but they have bumped protobuf runtime as well as grpc runtime.