On Thu, Jun 13, 2024 at 4:57 PM Shengjing Zhu <z...@debian.org> wrote:
> On Fri, Jun 14, 2024 at 4:50 AM Shengjing Zhu <z...@debian.org> wrote: > > > > On Wed, Jun 12, 2024 at 6:10 AM Reinhard Tartler <siret...@gmail.com> > wrote: > > > > > > On Mon, Jun 10, 2024 at 8:19 AM Shengjing Zhu <z...@debian.org> wrote: > > >> > > >> On Mon, Jun 10, 2024 at 6:45 PM Reinhard Tartler <siret...@gmail.com> > wrote: > > >> > On Mon, Jun 10, 2024 at 2:48 AM Shengjing Zhu <z...@debian.org> > 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. > > > > > > > The ttrpc generator is used by containerd to generate code, but > > currently due to lacking protobuild in Debian, this is not implemented > > in containerd packaging. But I see you start to package protobuild, > > the ttrpc generator could be kept. > Yupp, protobuild is currently in NEW: https://ftp-master.debian.org/new/protobuild_0.3.0-1.html I needed it for the go-fix-acronyms hack that post-modifies the generated protobuf golang code. https://salsa.debian.org/siretart/golang-github-containerd-cgroups/-/commit/83cae8e7d9b7fb78cedc4922c4395fe84d79e921 Next thing to work on: containerd > > > BTW despite the thread title is about grpc transition, we end up in > the trap of protobuf transition. > Since grpc-go has (finally!) switched golang-google-protobuf-dev in > recent version, I think we could decouple these two transition. I may > look at grpc-go this weekend. > Indeed, that appears to be the case in https://github.com/grpc/grpc-go/releases/tag/v1.64.0 let's see if we can get that into experimental, I think that's a great start. BTW, since I didn't hear otherwise from you, it appears this ttrpc/grpc/containerd mess is the actual blocker for upgrading protobuf/grpc. Let's proceed with those upgrades in experimental and see that we end up with a working docker26 and podman. Then let's reconsider what's left to fix for uploading to unstable. -- regards, Reinhard
