Re: Plans for golang-goprotobuf to unstable?
Am 20. November 2022 20:23:49 MEZ schrieb 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?
Not to be updared, but golang-github-google-cel-{go,spec}-dev are direkt dependencies of caddy and since ever stuck in experimental because of this.
>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.
I see the problem :(
An alternative that I consider is vendoring grpc/genproto apiv2 within golang-github-google-cel-spec-dev so that hopefully caddy can migrate to bookworm eventually... But that would not help other Go packages with the facing problem
Peymaneh
Reply to: