Stephen Kitt <skitt@debian.org> writes: > 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. I don't disagree, but this isn't what the Go team policy suggests right now, I think? I'm a newcomer here so I don't have any informed opinion on how things "ought to be". However I'm sure I fully agree with you either, due to: 1) this isn't exactly the same as C libraries since we don't use different Debian source packages for two different ABI versions for C libraries (although I think we sometimes used to do that...). 2) Earlier discussion suggests that packaging two or more Go major versions of a package in the same Debian source package is not a good idea. 3) Sometimes a package work fine using a Build-Depends of any of v2, v3, or v4, and no particular specific version is needed, and introducing a particular version causes unnecessary churn. 4) Sometimes a package ends up needing both a v2 and v4 of some library co-installed, and depending on file layout those packages will end up Conflict:ing because they re-use the same file paths for the majority of files. We don't unconditionally mirror the vX part in the /usr/share/gocode paths (but maybe we should?). 5) Consistency is nice, and my impression is that there are many multi-versioned golang-* packages in Debian that doesn't follow your suggested pattern. So if we change anything, it would be nice to update the Go team policy and make an effort to keep things compliant with it. (Updating the Go team policy to instead be silent on this topic is one solution...) /Simon
Attachment:
signature.asc
Description: PGP signature