On Sat, 13 Dec 2025 16:30:15 +0100, Simon Josefsson <simon@josefsson.org> wrote: > The golang-github-cenkalti-backoff transition is in progress. One thing > that I found about this is that some packages uses the following in the > *.go source code files: > > import ( > ... > "github.com/cenkalti/backoff" > > with go.mod saying something like: > > github.com/cenkalti/backoff v2.1.1+incompatible > > or they don't have a go.mod at all, and some packages uses > > import ( > ... > "github.com/cenkalti/backoff/v4" > > with go.mod saying: > > require ( > github.com/cenkalti/backoff/v4 v4.3.0 > > The former packages needs patching to pick up the right /v4 namespace, > whereas the latter just needs B-D/D to say > golang-github-cenkalti-backoff-v4-dev instead of > golang-github-cenkalti-backoff-dev. > > This is a curiosity and for future reference, I suspect we'll have other > similar transitions. > > I wonder if there is something in upstream Go libraries that lead to > packaging using versioned vs unversioned import statements. Is there > any Go ecosystem guidlines on what to use? Or is this per package, > depending on what the particular Go library recommends as its namespace? We had this entire discussion a couple of months ago: https://lists.debian.org/debian-go/2025/10/msg00013.html github.com/cenkalti/backoff and github.com/cenkalti/backoff/v4 are different major versions of the libraries, and there’s no guarantee that imports of the former can be patched to use the latter — the reason there’s a v4 instead of the implied v1 (with no version suffix) is that v4 broke the API (as did v2 and v3 presumably, and again v5). Different major versions of Go libraries should be treated in the same way as different sonames in C libraries, that is to say, with different packages. Since the version suffix in Go is part of the API, I still think there should be different -dev packages with the version suffix, and no “default” -dev package — because the versionless -dev package is effectively the v1 package. It is desirable to reduce the number of packages we need to maintain of course, but that should be dealt with by bumping the dependencies upstream where possible, not by developing Debian-specific patches. Regards, Stephen
Attachment:
pgpanxIOQeqC9.pgp
Description: OpenPGP digital signature