On 10/6/25 07:33, Nicolas Peugnet wrote:
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/11I 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
It is implied from the two points I made in <https://lists.debian.org/debian-go/2025/10/msg00018.html>.
Point #1 of my email was talking about different major versions of the same Go module, but the same argument also applies to different Go modules packaged by the same source package. For example, if source package golang-foo produces golang-foo-a-dev and golang-foo-b-dev, and upstream's foo/a package is at version 1.2.3 and foo/b at 0.23.6, then either: * one or both of the versions of the *-dev packages won't match their upstream versions, or * one or both of the versions of the *-dev packages won't match the source package's debian/changelog version.
If foo/a and foo/b have the same version now, they might not in the future. In particular, one of the two modules might get a change that breaks compatibility, and a /v2 suffix added to the module path as a result.
If upstream guarantees that foo/a and foo/b will always have the same version, point #2 still applies.
Point #2 was talking about different major versions of the same Go module, but it also applies to different Go modules packaged by the same source package. More on that below.
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 (ororig 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 inthe 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 onusers trying to understand what changed when an update is available.* One of the modules might be moved to a separate repository in the futurewithout 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 dependencybugs. 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-PathSo there is a clear association between this property and binary packages.
If I correctly understand how user-defined fields work, it is not possible to give different binary packages produced by the same source package different values of Go-Import-Path. Even if the field was changed from XS-* to XB-*, the XB-* field itself goes in the source package stanza, not the binary package stanzas, and its one value is copied to every binary package.
For example, if you search https://api.ftp-master.debian.org/binary/by_metadata/Go-Import-Path for golang.org/x/oauth2, you'll get two results: golang-golang-x-oauth2-dev and golang-golang-x-oauth2-google-dev. Which package is the correct provider of golang.org/x/oauth2? To a human the right answer is obvious, but dh-make-golang gets it wrong.
And what if you want the name of the binary package that provides the golang.org/x/oauth2/google module? That module path isn't listed anywhere, even though it is provided by the golang-golang-x-oauth2-google-dev package.
We could migrate to something like this instead:
XS-Go-Module-Paths:
golang-golang-x-oauth2-dev=golang.org/x/oauth2
golang-golang-x-oauth2-google-dev=golang.org/x/oauth2/google
This would allow dh-make-golang to correctly determine which binary
package is associated with which module dependency, and it would allow
dh-golang to determine the proper installation directory for each binary
package it builds. Or we could do this:
XS-Go-Module-Paths:
golang.org/x/oauth2
golang.org/x/oauth2/google
and let the consumer of this field derive the associated binary package
names using well-known conversion rules.
Neither of these alternatives would address point #1, so I think it is best to leave XS-Go-Import-Path alone for now, and prohibit multiple modules in the same source package.
-Richard
[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