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. -- Shengjing Zhu
