Hi, On Mon, 6 Oct 2025 13:33:07 +0200, Nicolas Peugnet <nicolas@club1.fr> wrote: > 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 Both points are related. XS-Go-Import-Path is only defined in source packages; and while it’s possible to find the path for a binary package as you point out, every binary package only has the path of its source package. Thus it’s impossible for a source package to build different binary packages for different module paths, which means a single source package can only package a single module. Regards, Stephen
Attachment:
pgppunzeB7L4M.pgp
Description: OpenPGP digital signature