On Fri, 2024-02-16 at 15:19 +0100, Simon Josefsson wrote: > What do you think about this approach to get modern grpc into unstable? > Here is grpc: https://tracker.debian.org/pkg/golang-google-grpc > > 1) Upload a new package golang-google-grpc-legacy identical to > golang-google-grpc 1.38.0+really1.33.3-1 from unstable. > > 2) Wait for golang-google-grpc-legacy to clear NEW. > > 3) Upload new versions of all the packages that FTBFS with modern grpc > (see list of ~10 packages in e-mail quoted below) to experimental, > changing their Build-Depends from golang-google-grpc to > golang-google-grpc-legacy. > > 4) Verify they packages all build fine, passes self-tests and seem to > work, and then upload them to unstable. > > 5) Rebuild all remaining reverse dependencies of grpc using version 1.60 > (or newer, I see 1.61 has been released while we are working on this..) > to make sure they are building properly. > > 6) Upload grpc 1.60 to unstable. > > 7) Upload all packages that need grpc 1.60 currently stuck in > experimental, into unstable. > > We can then work on resolving the problems in the FTBFS packages > incrementally until they are all moved from golang-google-grpc-legacy to > golang-google-grpc. > > Would this scheme work? I haven't thought it through or tested it, just > came up as some frustration trying to fix the FTBFS packages... > > I'll try to take a look at some more of the FTBFS packages below, but my > lack of Go knowledge is a limiting factor...
To me it seems like the extra work to try to keep a small set of packages building with a "golang-google-grpc-legacy" package wouldn't be worthwhile in the long term. I'd prefer effort be focused on getting the current grpc working in experimental, and uploading identified problem packages (with updates) into experimental until they are all fixed. We could then transition all the experimental versions into unstable at the same time. In the couple of years I've been doing go packaging, grpc has probably been the most challenging problem to encounter. But, we're early in the trixie development cycle so hopefully this can be figured out with plenty of time before freezes start. One of the tricky things, as I understand it, is that programs might happily compile with a newer version of grpc/protobuf, but when actually run they can crash due to version mismatches. So we'd need to exercise the protobuf codepaths in each updated package to make sure things work. Also, we'll probably want to open a transition bug with the release team to properly track things. Mathias
signature.asc
Description: This is a digitally signed message part
