Hi!  It would be nice to get v5 into unstable, 'sbctl' depends on that.
I uploaded 5.0.3 to experimental, but testing suggests it breaks most
reverse build dependencies:

https://salsa.debian.org/jas/golang-github-cenkalti-backoff/-/pipelines/949165

Maybe v4 could be split off into a new source package, and those
packages that still need it could depend on that?

Or this package becomes a v4+v5 package somehow, which I find a bit
ugly, but may be a simpler way forward.  We are talking about <1000
lines of code, most of it self-tests and license boiler plate.

Thoughts?

/Simon

All,

Does anyone have any suggestion how to proceed here?

We have github.com/cenkalti/backoff v4 in forky, and that package is not
many lines of code.  We have V5 in experimental, but it breaks almost
all of our packages:

https://salsa.debian.org/jas/golang-github-cenkalti-backoff/-/pipelines/949165

Is it feasible to get all of those packages updated to v5?

The API differences seems complicated, and I definitely not feel up to
patching code here.  Proper backoff algorithm handling may be rather
sensitive.

Could we add another orig.tar component (or just vendor them) with the
v5 sources, and expose that under a different name (maybe just
/usr/.../github.com/cenkalti/backoff/v5?) and patch all packages that
requires the v5 API to use that namespace?

The difference between v4 and v5 is ~1000 lines of code.

In the bug report below I say 'sbctl' but it is really
'golang-github-transparency-dev-tessera' which has ITP
https://bugs.debian.org/1102648 that needs v5.  It is targetting
experimental now, but eventually we want that in unstable.

Another idea is to patch 'golang-github-transparency-dev-tessera' to use
the v4 API.  But doing that feels backwards.

/Simon

Simon Josefsson <simon@josefsson.org> writes:

Hi Simon,

if it is such a big diff maybe package it as it were a new library and
add a -v5 suffix?
Not elegant, but then v4 and v5 would be available.

Best regards,
Martin

Hi Simon,

I really don't see a way around getting through the NEW queue and
introducing a new source package here.

Since golang-github-cenkalti-backoff is already at v5 in experimental, I
suggest we package v4 as src:golang-github-cenkalti-backoff-v4 which
produces golang-github-cenkalti-backoff-v4-dev.

This -v4 package would then live in unstable side-by-side with the v5 code
in the existing binary packages. This will break existing packages, which
will need to be fixed by either porting them to v5, or updating
debian/control to build against golang-github-cenkalti-backoff-v4-dev.

This approach is very similar to the common practice in Rust.

Best regards,

regards,
    Reinhard

Hi,

..
to do. The package name that is "versionless" should be reserved for
the latest version, and if older versions are needed to be kept
around, they should have the version suffix. Reinhard mentioned that
Rust packages do this, and I have also done this in e.g. Godot where
src:godot is the latest version (4.x) and src:godot3 is kept around
for anything that still depends on it and will be maintained until
upstream stops publishing security releases, or until nothing in
Debian uses it anymore.

From the Salsa CI reverse builds dep job you shared I can see these
are failing. Seems indeed majority (but not all) are failing on
dependency on cenkalti/backoff/v4. Many of the packages are already
using v5 upstream and would be fixed by simply updating the package,
but not all. This topic also ties into the general question that who
is expected to update what and when. As time goes by, Debian gets more
and more packages that sit at a specific version for years

build-rdep-deck 1.4.0 from 2021 (latest 1.54)
src/github.com/kong/deck/diff/diff.go:28:17: undefined: backoff.WithMaxRetries
src/github.com/kong/deck/diff/diff.go:424:5: in call to backoff.Retry,
type backoff.BackOff of defaultBackOff() does not match
backoff.Operation[T] (cannot infer T)

build-rdep-docker.io 27.5.1 (latest 29.1.2, upstream has v5 already in
https://github.com/moby/moby/blob/master/go.mod#L149 since v29.1.0)
src/go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetricgrpc/internal/retry/retry.go:17:2:
cannot find package "github.com/cenkalti/backoff/v4" in any of:

build-rdep-gh 2.46.0 from January 2025 (latest 2.83)
src/github.com/cli/cli/v2/internal/codespaces/codespaces.go:11:2:
cannot find package "github.com/cenkalti/backoff/v4" in any of:

build-rdep-golang-github-lestrrat-go-backoff 2.0.8 from 2021 (upstream
dead since)
src/github.com/lestrrat-go/backoff/bench/backoff_test.go:30:16:
undefined: cenkalti.WithMaxRetries

build-rdep-golang-github-maxmind-geoipupdate 6.1.0 from March 2025
(latest 7.1.1, unrelease upstream already has v5 support)
src/github.com/maxmind/geoipupdate/pkg/geoipupdate/database/http_reader.go:17:2:
cannot find package "github.com/cenkalti/backoff/v4" in any of:

build-rdep-golang-github-ovn-org-libovsdb 0.8.1 from Oct 2025
(upstream does *not* support v5 yet)
src/github.com/ovn-org/libovsdb/client/client.go:18:2: cannot find
package "github.com/cenkalti/backoff/v4" in any of:

build-rdep-golang-github-r3labs-sse 2.10 from Feb 2025 (upstream dead)
src/github.com/r3labs/sse/client.go:19:2: cannot find package
"github.com/cenkalti/backoff/v4" in any of:

build-rdep-golang-github-xenolf-lego 4.9.1 from 2023 (latest 4.29.0)
src/github.com/go-acme/lego/acme/api/api.go:12:2: cannot find package
"github.com/cenkalti/backoff/v4" in any of:

build-rdep-golang-github-zorkian-go-datadog-api
src/github.com/zorkian/go-datadog-api/request.go:196:5:
bo.MaxElapsedTime undefined (type *backoff.ExponentialBackOff has no
field or method MaxElapsedTime)
src/github.com/zorkian/go-datadog-api/request.go:228:33: in call to
backoff.Retry, type *backoff.ExponentialBackOff of bo does not match
backoff.Operation[T] (cannot infer T)

build-rdep-golang-gvisor-gvisor
src/gvisor.dev/gvisor/runsc/cgroup/cgroup.go:581:16: undefined:
backoff.WithContext
src/gvisor.dev/gvisor/runsc/cgroup/cgroup_v2.go:183:15: undefined:
backoff.WithContext

build-rdep-golang-opentelemetry-otel
Can't stat exporters/jaeger/internal/third_party/thrift/NOTICE: No
such file or directory

build-rdep-gost
src/github.com/knqyf263/gost/notifier/slack.go:60:20: undefined:
backoff.RetryNotify

build-rdep-incus
src/github.com/lxc/incus/internal/server/network/ovn/ovn_icnb.go:13:2:
cannot find package "github.com/cenkalti/backoff/v4" in any of:

build-rdep-prometheus-alertmanager
src/github.com/prometheus/alertmanager/notify/notify.go:25:2: cannot
find package "github.com/cenkalti/backoff/v4" in any of:

build-rdep-prometheus-sql-exporter
src/github.com/justwatchcom/sql_exporter/job.go:223:5:
bo.MaxElapsedTime undefined (type *backoff.ExponentialBackOff has no
field or method MaxElapsedTime)
src/github.com/justwatchcom/sql_exporter/job.go:224:8:
bo.MaxElapsedTime undefined (type *backoff.ExponentialBackOff has no
field or method MaxElapsedTime)
src/github.com/justwatchcom/sql_exporter/job.go:225:6:
bo.MaxElapsedTime undefined (type *backoff.ExponentialBackOff has no
field or method MaxElapsedTime)
src/github.com/justwatchcom/sql_exporter/job.go:227:37: in call to
backoff.Retry, type *backoff.ExponentialBackOff of bo does not match
backoff.Operation[T] (cannot infer T)

build-rdep-restic 0.18.1 (upstream still using v4)
src/github.com/restic/restic/internal/backend/local/local.go:21:2:
cannot find package "github.com/cenkalti/backoff/v4" in any of:

build-rdep-vuls
The following packages have unmet dependencies:
golang-github-olekukonko-tablewriter-dev : Breaks:
golang-github-kotakanbe-go-cve-dictionary-dev (<= 0.3.1-5) but 0.3.1-5
is to be installed

Reinhard Tartler <siretart@gmail.com> writes:
Both packages will provide

/usr/share/gocode/src/github.com/cenkalti/backoff/backoff.go

wouldn't they?  The packages could Conflict with each other, but I don't
think that will fly: I'm sure some package will end up recursively
depending on both.

How about putting the golang-github-cenkalti-backoff-v4-dev files into

/usr/share/gocode/src/github.com/cenkalti/backoff/v4/backoff.go

and then, for all packages without upstream v5 support, update
build-depends to golang-github-cenkalti-backoff-v4-dev and add a patch
that changes which namespace to use?

"Martin Dosch" <martin@mdosch.de> writes:

This is the simplest path forward, but it becomes really ugly when a v6
comes out.  I think the "right" package name should be reserved for the
latest upstream version, and that we introduce a new v4 package and
patch all consumers is better.

Otto Kekäläinen <otto@debian.org> writes:

Great, we have some agreement on this then.
I just did a small transition of golang-github-ccoveille-go-safecast via
experimental that required new uploads of
golang-github-tillitis-tkeyclient and
golang-github-smallstep-certificates which I staged in experimental for
testing.

But for golang-github-cenkalti-backoff-dev I'm not sure this is
feasible.  Trying to update all packages and moving them into
experimental will take time, and stop progress for all involved packages
until the transition is over.  I'm not sure I can commit to finishing
this in a timely fashion, nor is that a good expectation to have for
contributions IMHO.

I think we agree that uploading a v4 package allows simple and safe
migration strategies.  It seems a bit wasteful to introduce a NEW
package which eventually will fade away, just to do a transition, but I
think the alternatives are worse.

Thank you for going through these!  I became exhausted just looking at
the list.

I'll wrap up a v4 source package and upload to NEW queue, we can sort
out the file conflicts later.

/Simon

I've uploaded to NEW:

https://salsa.debian.org/go-team/packages/golang-github-cenkalti-backoff-v4
https://salsa.debian.org/jas/golang-github-cenkalti-backoff-v4/-/pipelines/988017

Review appreciated!  I think everything except naming can be resolved
after it passes NEW review.

Is 'XS-Go-Import-Path: github.com/cenkalti/backoff/v4' the right thing?
I'm not sure if that is the best way to add the /v4/ file-name suffix.
Something to avoid filename Conflicts will probably be needed, but it
could be done in other ways too.

/Simon

Hi Simon,

Regarding the file conflict issue, how about having the
golang-github-cenkalti-backoff-v4-dev files installed under a subdirectory
like /usr/share/gocode/src/github.com/cenkalti/backoff/v4/ and the existing
v5 files installed under /usr/share/gocode/src/
github.com/cenkalti/backoff/v5/?

While this approach might still cause breakage in some packages that expect
a simple, versionless import path, I expect it would require less overall
patching across all of Debian and keeps the package structure closer to how
Go upstream handles versioned imports.

Best regards,

Reinhard

regards,
    Reinhard

Reinhard Tartler <siretart@gmail.com> writes:

https://ftp-master.debian.org/new/golang-github-cenkalti-backoff-v4_4.3.0-2.html

My question was more if 'XS-Go-Import-Path:
github.com/cenkalti/backoff/v4' is the right way to achieve that, or has
that header some other semantics that I'm unaware of?

Do we need that?  Can't the normal golang-github-cenkalti-backoff-dev
package be a normal packaging of that project, using regular
'dh-make-golang make' defaults?

If the *-v4-dev package puts the file into v4/ there is no conflict with
v5 files in ../.

The only breakage with the above scheme is in packages that are stuck on
v4, which may need a patch to use our v4 namespace.  But that is
expected, and as Otto analyzed, we can hopefully migrate most of those
packages to v5 once we have both in unstable.

Actually we can migrate them to v5 by putting new upstream uploads into
experimental now.  I prefer to get the *-v4-dev package into unstable
first, and then upgrade all of the reverse dependencies from *-dev to
*-v4-dev without bumping upstream version first though.  But we can do
anything in experimental while unstable is undisturbed.

/Simon

Hi Simon,

Yes, you are correct. My understanding is that the api version component at
the end of the XS-Go-Import-Path field should only be omitted for V1 (the
versionless default). Later versions of the API, such as v4 and v5, should
be placed in their respective subdirectories (/v4/, /v5/) for the golang
module path lookup to work as expected.

At least that's my current understanding of the situation.

regards,
    Reinhard

However 'dh-make-golang make' never sets that up, nor have I seen this
in any common use?  We have plenty of v2, v3, v4, v5 etc in the archive
and very few seems to have XS-Go-Import-Path including the /vX part.

For example of a popcon heavy v5 package that doesn't use that approach:
https://salsa.debian.org/go-team/packages/golang-github-containers-image/-/blob/debian/sid/debian/control?ref_type=heads#L59

I guess I never understand the semantics of XS-Go-Import-Path.  The Go
team documentation doesn't really mention it at all except for this
quote:

    You will need to change the value of XS-Go-Import-Path in
    debian/control to correspond to your program’s upstream package
    name. This is usually what you would go get when installing it
    manually. dh-golang needs that information so that it can run go
    install.

If I understand how most Go packages work, the /vX is not part of the
"upstream package name" which I presume is the same as used in import
statements, although I'm not familiar with this terminology.

I think we can use /v4 for the *-v4-dev package, but doesn't need to
touch this for the normal (future v5) *-dev package.

/Simon

Reinhard Tartler <siretart@gmail.com> writes:

We believe that the bug you reported is fixed in the latest version of
golang-github-cenkalti-backoff-v4, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1121424@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon Josefsson <simon@josefsson.org> (supplier of updated golang-github-cenkalti-backoff-v4 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 10 Dec 2025 08:39:19 +0100
Source: golang-github-cenkalti-backoff-v4
Binary: golang-github-cenkalti-backoff-v4-dev
Architecture: source all
Version: 4.3.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team <team+pkg-go@tracker.debian.org>
Changed-By: Simon Josefsson <simon@josefsson.org>
Description:
 golang-github-cenkalti-backoff-v4-dev - exponential backoff algorithm in Go
Closes: 1121424
Changes:
 golang-github-cenkalti-backoff-v4 (4.3.0-2) unstable; urgency=medium
 .
   * Transition for golang-github-cenkalti-backoff.  Closes: #1121424.
     Thread: https://lists.debian.org/debian-go/2025/12/msg00016.html
Checksums-Sha1:
 06bb55f50e2d7d60ad32c2b0d8dd7f6708ab10e2 2970 golang-github-cenkalti-backoff-v4_4.3.0-2.dsc
 6fad2ceebc0e8092207098cfb8700abbf5b3b6f3 10973 golang-github-cenkalti-backoff-v4_4.3.0.orig.tar.gz
 55e44b7902fe7ab2b9e97fa4ed19e12fc5b1320b 3740 golang-github-cenkalti-backoff-v4_4.3.0-2.debian.tar.xz
 4f0886c2222ebe2396abcd64a7129821113a9c02 12104 golang-github-cenkalti-backoff-v4-dev_4.3.0-2_all.deb
 cc07577217f08bb4bf44f7cfcc79f1941eec1141 6446 golang-github-cenkalti-backoff-v4_4.3.0-2_amd64.buildinfo
Checksums-Sha256:
 3dca2a5810a8313e7b87a1b61322a2118e7f14836cafc8628b7ce2315c9cbc87 2970 golang-github-cenkalti-backoff-v4_4.3.0-2.dsc
 4544e05cc5d976fe2bf09c243840ef594b127526cd5600d95cb508141aaded54 10973 golang-github-cenkalti-backoff-v4_4.3.0.orig.tar.gz
 5725a7a45bc34c3ce0e71de63b9d651df116f7cd994fd562d262cdb65e0bf635 3740 golang-github-cenkalti-backoff-v4_4.3.0-2.debian.tar.xz
 9e5ca1e2a1e97c16e466089d0ecc9876b2e4f6498d910b1f97b1e5781ad47d68 12104 golang-github-cenkalti-backoff-v4-dev_4.3.0-2_all.deb
 f1a803ac39452194892948ef847604c7080a4e377bb1fcf9083c75db21027c46 6446 golang-github-cenkalti-backoff-v4_4.3.0-2_amd64.buildinfo
Files:
 9329696cec7830cbbc0fce087c613fbc 2970 golang optional golang-github-cenkalti-backoff-v4_4.3.0-2.dsc
 24184c025535eac11da6510542cf308b 10973 golang optional golang-github-cenkalti-backoff-v4_4.3.0.orig.tar.gz
 01222da402ed219fd0c30834678bc253 3740 golang optional golang-github-cenkalti-backoff-v4_4.3.0-2.debian.tar.xz
 749686810bdfc8bcb3666cc0ad552ae1 12104 golang optional golang-github-cenkalti-backoff-v4-dev_4.3.0-2_all.deb
 0e5399b768d26b64182034b5fb29b085 6446 golang optional golang-github-cenkalti-backoff-v4_4.3.0-2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmk5KL4UHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA
/iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx
+3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6
qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF
PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh
is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFok95AQCEobin+CNA
2d/cdXc/azFZrW7uOzMRZr2QlgBgmmhU2QEAobolJTmjnKzyzQ6sijgKKTWBLmQG
Emu2MIuRl8+nAAk=
=ZSJE
-----END PGP SIGNATURE-----

..
into debian/vendor/github.com/.../v4

In particular if:
- the dependency is not properly defined, a local debian/vendor/*
thing is easier to inject into the build
- the dependency is very specific, e.g. v4.x.y
- you don't want to go via NEW queue to introduce a -v4 package
- only one or _very few_ packages depend on it and no new packages
will ever depend on it

Otto Kekäläinen <otto@debian.org> writes:

Indeed, and having already gone through the trouble of getting
'golang-github-cenkalti-backoff-v4' quickly past NEW and in the process
of getting the 10+ reverse dependencies to use *-v4-dev and migrate them
to testing, I'm somewhat inclined to believe that vendoring v4 in the
otherwise v5 *-dev package would have been simpler.

Still, several of the reverse dependencies would still had to be patched
because of the versioned /v4/ vs unversioned imports that seems to be in
wide use for this package.

So I'm somewhat happy that I learned to do a migration like this, but
also unsatisfied because I think this is a lot of time spent on things
that nobody should have to spend time on.

Once this golang-github-cenkalti-backoff-v4 transition is completed, I
think the end result will be nicer than any of the alternatives, though,
including the vendoring approach.

This process is feasible to do for a ~10 package migration, but I'm not
sure we should do it for 100+ packages, if there is ever a need for
that.  At least not for a one-person assignment.  Embedding two versions
of the same upstream into the same Debian source package is less work,
produce the same end result, but may violate some policies.

/Simon

Hi Simon,

I tend to agree with your conclusion here.

The current situation with containerd2 is very similar: it's currently
stuck in the NEW queue, and I packaged it as a separate source package due
to its completely new API. However, we have many existing packages that
still rely on the v1 API. To complicate matters, the dedicated API package
for communication has also moved from v1 to v2.

Vendoring the v1 dependency within the existing packages would certainly
make the transition significantly easier by providing a safe migration path.

I think I'll do that in experimental and see how it goes. Thanks for
sharing your thoughts!