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.
Forcing a bunch of changes every time a new vY is introduced feels brittle to
me. Compare these scenarios with packages A, B, C using foo v4, and a new
desired package D using foo v5:
* if foo v4 is golang-foo and golang-foo-dev, and we introduce golang-foo-v4
and golang-foo-v4-dev so that golang-foo can be v5 instead, everything is
blocked until A, B, C are updated
* if foo v4 is golang-foo-v4{,-dev}, A, B, C remain unchanged, and a new
golang-foo-v5 is introduced for D (and can be used of course by A/B/C
if/when they switch to v5)
The latter approach also has the added benefit that upgrades to v4 can be
handled in parallel to v5, without having to take care of migrations
involving suffixless packages. It’s reasonably common for projects to
publish new releases on multiple branches in similar timeframes, and we might
at some point in the future want to be able to update v4 without having to
wait for a migration involving v5.
Not requiring a migration in A/B/C also means that A/B/C can live their lives
without requiring coordination around migrations.
Regards,
Stephen
Attachment:
pgpwhDrMtAU6C.pgp
Description: OpenPGP digital signature