Re: golang-github-cenkalti-backoff v4->v5 migration, ITP of v4 vs v5?

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 <simon@josefsson.org> 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