Hi Modern golang-github-sigstore-* needs golang-github-transparency-dev-tessera which doesn't build because Debian has golang-github-cenkalti-backoff v4 but v5 is required: https://salsa.debian.org/jas/golang-github-transparency-dev-tessera/-/jobs/8385295 I did a baseline reverse dependency build: https://salsa.debian.org/jas/golang-github-cenkalti-backoff/-/pipelines/949124 which can be compared with building v5: https://salsa.debian.org/jas/golang-github-cenkalti-backoff/-/pipelines/949165 As you can see, the golang-github-cenkalti-backoff v4->v5 API changes are significant, and almost all ~15 reverse dependencies fail. Any thoughts on handling this? Naively I can think of two ways forward: 0) Somehow patch out this dependency from golang-github-transparency-dev-tessera. 1) ITP a golang-github-cenkalti-backoff-v5 for the new API and use it. 2) ITP a golang-github-cenkalti-backoff-v4 as a copy of the current packaging, update all reverse dependecies replacing golang-github-cenkalti-backoff-dev with golang-github-cenkalti-backoff-v4-dev, and then package v5 as golang-github-cenkalti-backoff-dev and use that in golang-github-transparency-dev-tessera. The simplest way forward is 1) but if/once upstream releases v6 this becomes ugly, and the golang-github-cenkalti-backoff package will essentially be frozen on v4, and the golang-github-cenkalti-backoff-v5 package will have v6 which all seems a bit odd. I think we already have some example of this though. I'm inclined to go with 1) but if people are supportive of doing the work involved with 2) I could look into that. This assumes all ~15 packages are team-maintained and that I/someone will need to do ~15 essentially no-op uploads for these packages. Of course, best is if those upstreams move to v5 but that seems rather wishful thinking. /Simon
Attachment:
signature.asc
Description: PGP signature