On Sun, 05 Oct 2025 11:20:02 +0200, Simon Josefsson <simon@josefsson.org>
wrote:
This is all convincing to me, so I'm changing my mind here. One source
package per upstream Go project, for each significantly different API
version. But how to name these?
- golang-import-path source package always tracks latest upstream when
there is a need for that library in debian
- golang-import-path-dev binary package to track latest upstream, from
the golang-import-path source package
What about projects with a suffixless v0 or v1, still used by reverse
dependencies, and v2 or further?
- golang-import-path-v3 source package for older API versions that are
still needed in Debian
- golang-import-path-v3-dev binary package built from
golang-import-path-v3 for as long as this API is still needed to
pacify reverse dependencies who hasn't upgraded to latest version.
For library API migration -- such as for
https://tracker.debian.org/pkg/golang-github-cenkalti-backoff which is a
good example -- we should NEW the current package into
golang-github-cenkalti-backoff-v4, change all ~15 reverse dependencies
to use golang-github-cenkalti-backoff-v4-dev instead, and then update
golang-github-cenkalti-backoff to provide v5.
Would this work?
Wouldn’t it be better to always have the version in the package names? /vX is
a significant difference in the Go ecosystem anyway, so forcing maintainers
to choose the appropriate -vX-dev package based on their packages’
dependencies feels fine to me. You see foo/vX in go.mod, you use
golang-foo-vX-dev.