Re: golang-goprotobuf 1.4+ (Was Re: disruptive uploads)
On Sun, Aug 29, 2021 at 08:32:40PM +0200, Reinhard Tartler wrote:
> On Sat, Aug 28, 2021 at 8:23 PM Shengjing Zhu <zhsj@debian.org> wrote:
>
> > golang-goprotobuf is special so let's start a new thread.
> >
>
> good call!
> [...]
>
> Now the question for Debian to move forward.
> > 1. Should we bump golang-goprotobuf to v1.4+, this will break packages
> > that still uses golang-gogoprotobuf, and unlikely will be fixed.
> > 2. Should we stick golang-goprotobuf at v1.3, and only go with
> > golang-google-protobuf package?
> > This means we need to help upstream to finish the transition to
> > protobuf v2 with golang-google-protobuf only.
> >
> >
> It seems that we currently have 243 packages declaring a "Build-Depends"
> relationship in unstable on the old 1.3 golang-gogoprotobuf package, and
> "only" 7 on the new golang-google-protobuf-dev. That's an awful lot of
> breakage.
>
> Shengjing, would it be feasible to keep golang-gogoprotobuf at 1.3 and have
> packages move over to google-protobuf-dev "peu-a-peu"? In principle, I
I still don't understand. golang-gogoprotobuf will probably be at 1.3 forever
as there's no upstream development now.
Only golang-goprotobuf may migrate to golang-google-protobuf, as both are
developed by Go team(Google).
> think option 1 would be preferable if the goal is to move to protobuf v2 as
> fast as possible. Given the vast amount of packages that need porting, I'm
> not sure that we'd have the necessary engineering capacity for getting this
> done in a timely manner. If version 2 is feasible, and we can keep both the
> old and the new API available, we could give the various upstreams more
> time to port to the v2 API on their own time while allowing packages that
> require the v2 API today in testing now.
>
> If that's not feasible, we'd have to go with option 1, read: update
> golang-goprotobuf to v1.4 breaking potentially over a hundred packages,
> have them removed from testing, work with upstreams to move to the new API
> and hope to "rescue" as many packages as possible before the next freeze.
> That, however, will be very painful as those packages might not be
> available even in unstable and a major inconvenience for everyone involved.
> I think we'd rather want to avoid this scenario.
>
The difficulty is for example github.com/gogo/protobuf is not developed any more,
and some packages which depend on it are stuck at it for a long time.
> Maybe there is another option I'm not seeing?
I think it again, maybe we should have both v1.3 and v1.4+ golang-gogoprotobuf together,
as we do the transition in C/C++ libraries. Some packages are difficult to be ported
to new api, so we end up with two duplications in archive.
Reply to: