On Thu, Jan 07, 2021 at 04:43:43PM +0800, Shengjing Zhu wrote:
On Thu, Jan 7, 2021 at 2:51 PM Anthony Fok <f...@debian.org> wrote:
Hi Shengjing,
On Tue, Jan 5, 2021 at 8:42 AM Shengjing Zhu <z...@debian.org> wrote:
>
> Hi Anthony,
Thanks for writing to me! Sorry for the late reply.
I was going to re-open this with the pseudo header "Control: reopen
-1" to keep this new version out of testing (buster), but then I
decided to study the issue further, I think we are safe to move
forward, allowing golang-google-protobuf to enter testing, while
keeping the old golang-goprotobuf 1.3.x if necessary.
> The reason that I haven't uploaded new version of this package, is
> that using golang-google-protobuf usually means using
> golang-goprotobuf 1.4+ as well.
Looks like that is not the case any more.
While golang-google-protobuf and protoc-gen-go v1.25.0 would still
pull in the old golang-goprotobuf 1.4+ package in the generated file,
apparently for backward compatibility during the 6-month transition
period that Joe Tsai @dsnet set:
import (
proto "github.com/golang/protobuf/proto"
...
)
Well, I think we have good news!
1.25.0+git20201208.160c747 doesn't do that any more.
The import proto "github.com/golang/protobuf/proto" line is gone;
the "const _ = proto.ProtoPackageIsVersion4" is also gone.
The latest golang-google-protobuf makes a clean break from the past.
It is now self-contained, and no longer pulls in the legacy golang-goprotobuf.
It is just like what you predicted: once GitHub issue #1077 is fixed,
we can move forward.
Thank you for your packaging of golang-google-protobuf which also
allows the clean separation with the old golang-goprotobuf ecosystem.
The problem is currently all upstream still use golang-goprotobuf to
generate pb.go, not the plugin from
https://github.com/protocolbuffers/protobuf-go/tree/master/cmd/protoc-gen-go
If we choose to use this plugin ahead of upstream, and leave
golang-goprotobuf not updated(and not used in B-D), then things will
be fine. But upstream says there are still missing features like grpc
support, which are moved to grpc package itself. I haven't looked at
this part. However it will become a difficult transition, which
involves golang-google-grpc-dev, golang-google-genproto-dev, etc...
But those issues are not made worse by allowing golang-google-protobuf
to go in, right?
What's blocking golang-google-protobuf from moving to testing now that
the dependency on golang-goprotobuf is no longer there?
Is the issue that golang-google-protobuf source also builds a
protoc-gen-go?
Why can't the latter be split, so upstreams that include pre-generated
.pb.go (as is the official recommendation) can be included in Debian
as-is using the corresponding dependency?
Thanks!
Alberto
