Hi Simon, Thanks for looking into these options. I agree that option 1, which involves creating a `golang-github-cenkalti-backoff-v5` source package for the new API, seems to be the most straightforward approach to handle this migration.
In parallel and in order to not be blocked by waiting on NEW, you may consider temporarily vendoring cenkalti/backoff/v5 into the new sigstore packages. > 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. The rust team chooses 2, and has that documented at https://rust-team.pages.debian.net/book/process-single.html#co-installable-older-versions-versioned-or-semver-suffixed-packages. Arguably, it is easier for the rust team because of tooling that the team has built around managing many packages. I can also get behind that approach for golang, if there is team consensus in the Golang team. As far as I can tell, 1) is currently more common in the Golang team. Best regards, Reinhard On Thu, Oct 2, 2025 at 9:15 AM Simon Josefsson <[email protected]> wrote: > 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 > -- regards, Reinhard
