Re: Plans for golang-goprotobuf to unstable?

[Shengjing Zhu <zhsj@debian.org>]

On Mon, Nov 21, 2022 at 2:53 AM Peymaneh <peymaneh@posteo.net> wrote:
>
> Hi,
>
> Am 26.10.22 um 20:27 schrieb Shengjing Zhu:
> > Hi all,
> >
> > On Sun, Jul 10, 2022 at 6:53 AM Shengjing Zhu <zhsj@debian.org> wrote:
> >>
> >> I should have mentioned it earlier. For this particular transition
> >> (google/protobuf 1.3 -> 1.4+), ratt is not enough. For example,
> >> containerd will panic at runtime (root cause is #975431). The
> >> incompatibility is not at compile time, but at runtime.
> >>
> >> For safety,  I think google/protobuf (>= 1.4) should mark Breaks:
> >> golang-gogoprotobuf-dev.  Otherwise all package maintainers should
> >> verify if the package is still functional after rebuilding.
> >
> > I just uploaded golang-github-golang-protobuf-1-5 to unstable.
> > So please keep golang-goprotobuf at 1.3, I will ask removing the 1.5
> > version in experimental shortly.
> >
> > If you're blocked _only_ by github.com/golang/protobuf v1.4+, then you
> > can start to use golang-github-golang-protobuf-1-5.
> >
> > There's still puzzle for the next steps. For example,
> > + golang-google-genproto, the pb.go files in new version need to be
> > generated by new protoc-gen-go. However by doing this, it will be come
> > incompatible with gogo/protobuf and cause runtime panic (you will not
> > notice build error).  This at least will break containerd, and then
> > all container tools like docker/podman.
> >
>
> I have two questions on this:
>
> 1. Would it be possible to have two versions for each
> golang-google-genproto(-dev) and golang-google-grpc(-dev) in the
> archives, one with regenerated pb.go files for api v2 and one that is is
> backwards-compatible api v1, resp. gogo/protobuf, that declare
> incompatibility on each other?
>

Do you have a list of packages that can be updated after new versions
of genproto and go-grpc are packaged as separated?

I have thought of doing this, but I end up giving up.

For example,

+ Lets have go-grpc-old and go-grpc-new, and they conflict with each
other since they have the same import path.
+ containerd wants go-grpc-old
+ docker build-depends containerd, and etcd.
+ etcd now has to depend on go-grpc-old.
+ someone want to update etcd, and it needs go-grpc-new. Now it
becomes impossible.
+ So we need etcd-old and etcd-new now.

I find it endless. So I give up in this direction.

-- 
Shengjing Zhu