Richard Hansen <rhansen@rhansen.org> writes: > On 10/5/25 02:18, Shengjing Zhu wrote: >> On Sun, Oct 5, 2025 at 2:02 PM Simon Josefsson <simon@josefsson.org> wrote: >>> >>> Shengjing Zhu <zhsj@debian.org> writes: >>> >>>> Thanks for raising this. >>> >>> We should have better guidelines on this. >>> >>> Would a general policy to always prefer "golang-import-path" as the >>> source package, and produce "golang-import-path-dev" package when there >>> is only one version in play, and have a multi-upstream tarball package >>> named "golang-import-path" for the source and >>> "golang-import-path-v3-dev" for OLD versions and >>> "golang-import-path-dev" to always track latest upstream version (when >>> that latest needed version is needed by some other package in debian) >>> work? >>> >>> The migration path for a library with many reverse dependencies stuck on >>> old versions would then be to introduce a new >>> "golang-import-path-v3-dev", change all reverse dependencies stuck on >>> that old version to use *-v3-dev instead of *-dev, and then let >>> "golang-import-path-dev" track v4, v5 or whatever is latest. This >>> requires a NEW roundtrip to add a new binary package name, which is a >>> hassle, but I find the alternatives to be worse. >>> >> Do you mean one source package which produces multi -vN binary >> packages, with the MUT tricky? Why not just have multi source >> packages? If you add a new binary package, you need to go through the >> NEW queue, the same as adding a new source package. > > There are a couple additional issues with multiple *-vN-dev binary > packages from a single source package: > > 1. The version of each binary package would ideally match the > upstream version (e.g., 2.1.0-1 for the *-v2-dev package, 3.2.1-1 > for the *-v3-dev package). Right? If so, that would mean that the > binary package versions wouldn't match the source package version in > debian/changelog. That seems like a maintenance headache, and a > burden on users trying to understand what has changed when an update > is available. > > 2. Each *-vN-dev binary package is associated with a different Go > module name (a.k.a. base import path). However, if I understand > correctly, the XS-Go-Import-Path field is a property of source > packages, not binary packages. If that's correct, then how would > dh-make-golang determine which of the binary packages it should use > when filling in a dependency of a new package? I guess it could > scan the package names looking for a matching -vN-dev suffix, but > that seems unnecessarily complicated and fragile. > > For an example of #2, try packaging something that depends on > golang.org/x/oauth2 (e.g., github.com/coreos/go-oidc/v3). Because the > golang-golang-x-oauth2 source package builds both > golang-golang-x-oauth2-dev and golang-golang-x-oauth2-google-dev, > dh-make-golang will incorrectly use golang-golang-x-oauth2-google-dev > as the dependency. 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 - 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? One problem is if some of the ~15 reverse dependencies aren't maintained by the Go team. This happens sometimes, and then we don't have authority to upload those packages. But we can try to convince others to follow this approach. I'll check if this would work for golang-github-cenkalti-backoff. How would we update the Go team policy to say this? It would be nice to merge https://go-team.pages.debian.net/packaging.html with https://go-team.pages.debian.net/workflow-changes.html into a self-contained "Go Team Policy" document with all the latest thinking. /Simon
Attachment:
signature.asc
Description: PGP signature