On 10/5/25 02:18, Shengjing Zhu wrote:
On Sun, Oct 5, 2025 at 2:02 PM Simon Josefsson <[email protected]> wrote:
Shengjing Zhu <[email protected]> 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.
