Mathias Gibbens <gibmat@debian.org> writes: > 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. Fair enough -- do you have some ideas based on the FTBFS build logs? The errors looks similar in several packages, and I have a feeling it is only a matter of upgrading some dependency package, but understanding WHICH dependency package to upgrade to fix an error messages is a bit of a mystery to me... > 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. That is an good reason to add more debci/autopkgtest for Go packages with binaries, so we catch such problems early during testing and not on live systems. If we have some test in debian/tests/ that attempts to run the binary and use it for something relevant, I'm hoping that would trigger any grpc/protobuf mismatch problem? > Also, we'll probably want to open a transition bug with the release > team to properly track things. If we manage to fix all reverse dependencies in unstable (around 10 packages left), then we don't need a transition right? Just fix all packages in unstable that doesn't build with modern grpc, and once reverse builds of grpc > 1.60 works, then upload grpc to unstable. It would be nice to rebuild all binaries that depend on grpc < 1.60 to get security fixes though, but that could be scheduled as binNMU's or some cleanup upload. /Simon
Attachment:
signature.asc
Description: PGP signature