Andrew Lee <[email protected]> writes: > Hi Simon and Arthur, > > On Tue, Sep 1, 2026 at 8:34 AM Simon Josefsson <[email protected]> wrote: >> introduce -v6 packages just because. Sometimes upgrading a v4 to v6 >> goes painlessly and there is just one or two reverse dependencies that >> can easily be fixed. But when it doesn't, we are often stuck, and then > > Yes, option 2 the best recommended practice to going forward. The > major versioning as /v4, /v6 is just like soname versioning. We > sometimes should keep both versions available in the Go Ecosystem in > Debian if upstream are still keep maintaining both and applications > are still using both. The status of both versions can be verify easily > on https://pkg.go.dev. > > As we have been working on module-aware builds, we better to name the > source/binary package name in a consisten way to avoid confusions and > also make it work in both legacy GOPATH mode and Go Workspace mode in > this stage.
We should be aware that this is against normal Debian practices that imply one Debian source package per upstream project. We could rightly be challenged about this by other parts of Debian. I'm not even sure everyone in the Debian Go Team agree. I do think that we can make the argument that Go packaging deserves an exception to normal rule though, roughly: 1) The Go ecosystem API stability is less predictable than the traditional C ecosystem where ABI breaks are rare and painful occurances. 2) Instead of forcing Debian's assumption of API stability into the Go ecosystem, we can acknowledge reality: Go code will have more frequent API bumps. 3) The solution for Debian packaging of Go projects is to prepare one Debian source package for each API version, and make consumers of that particular API version depend on that Debian source package. 4) We already have tooling to detect Zombie packages which are no longer needed, so we have a garbage collector running. 5) We can develop tooling to detect when Debian contains two projects vX and vY where Y>X from the same upstream, and file a Severity:important bug on the vX package asking that all consumers of the package should file upstream bug reports asking upstream to migrate to vY (or later). I believe this is an acceptable trade-off for the project at large. /Simon
signature.asc
Description: PGP signature
