Hi, On 06/10/2025 09:00, Richard Hansen wrote:
I opened a merge request that hopefully covers what has been discussed, including rationale. Please let me know if I have omitted anything, or suggested anything undesirable.https://salsa.debian.org/go-team/go-team.pages.debian.net/-/ merge_requests/11
I don't see where the first point [1] of your proposed changes have been discussed, even after reading the full thread:
=== One Go Library Module Per Debian Source Package A Debian source package should package up at most one Go library module, even if another Go library module lives in the same upstream source code repository (or orig tarball). For example, `golang.org/x/oauth2` and `golang.org/x/oauth2/google` are two separate modules so they should be packaged separately despite both living in the https://cs.opensource.google/go/x/oauth2 repository. ===== Rationale * Each Go module might have a different version number. (If not now, then possibly in the future.) While it is technically possible to give each built Debian package a version that differs from the source package version in `debian/changelog`, doing so is a maintenance hassle as well as a burden on users trying to understand what changed when an update is available. * One of the modules might be moved to a separate repository in the future without changing its module path. * The `XS-Go-Import-Path` field in `debian/control` describes a property of the Debian source package, not a built package. If one Debian source package produces multiple built packages then `dh-make-golang` is unable to determine which built package is associated with which module path, causing dependency bugs. Also see the debian-go mailing list thread starting at https://lists.debian.org/debian-go/2025/10/msg00013.html.
Also about this:
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.
This property is indeed apparently not passed to the binary package [2], but it can be queried from the ftp-masters API: https://api.ftp-master.debian.org/binary/by_metadata/Go-Import-Path
So there is a clear association between this property and binary packages.[1] https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/11/diffs#9228f0ee4476498ad839837f5d976715eb7466f2_162_162 [2] https://www.debian.org/doc/debian-policy/ch-controlfields.html#user-defined-fields
-- Nicolas Peugnet