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.