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/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
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 (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.
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
