On Sun, Aug 29, 2021 at 08:32:40PM +0200, Reinhard Tartler wrote: > On Sat, Aug 28, 2021 at 8:23 PM Shengjing Zhu <[email protected]> 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.
