Hi Simon, Thank you very much for your input. Please allow me to reply to both of your input together.
You are right. C/C++ libraries keep the same source package name while changing binary package names. However, for Go packages, different import paths usually come from different upstream git tags or branches, and sometimes even in different hosts(eg: upstream rename to their new host, or migrate to codeberg). Here is a comparison between using `One Source Package` vs `Different Source Packages` for handling multiple major API versions: Fixing Bugs and Security Issues ========================= One Source Package: Requires complex branch management and build setup. Have to rebuilds all binary packages together in one source package update. Different Source Packages: Allows us to fix and update in one major API version without touching the other. Handling `go.mod` with Multiple Major Versions ==================================== One Source Package: Requires source package update to build multiple Major API version binaries setup and maybe requires to symlinks to handle upstream path name chanegs. Different Source Packages: Works simply, just like any independent package. Salsa Repository Management ======================== One Source Package: Needs special branch management to build multiple different Majro API version binaries from one single source package. Different Source Packages: Easy to maintain. We can fork the repository and keep most files under `debian/` as they are, without complex branching or build setup. And I agree that making this opt-in for new major versions `Sounds Easier`. :) However, skipping source package renames will causes problems for both new tooling and maintainers: Maintainer Confusion: It makes it much harder for maintainers to look up dependencies or quickly check if a specific Go import path is already packaged in Debian or not Directory Structure: dh-go expects the package to provide filesystem structure to match it's go import path when lookup modules. Build Failures: If the source package does not match the major version import path, dh-go cannot find the module root during the build. More Maintenance: Keeping legacy source package names allows us to keep old hacks in existing legacy packages, but required to add more hacks manually across all downstream packages and hacks also takes time for maintaining. Complex for maintaining/creating downstream packages. Conclusion ========= If we rename/fork source package to match the upstream go import path and provde the same directory structure from upstream. We can simply create different source package by fork the repo for Major API Version bump or upstream rename/migrate to new hosts. And Module-Aware Builds under Go Workspace with `dh-go` may work soomthly without needed to add extra hacks anymore. Happy hacking, -Andrew On Mon, Sep 7, 2026 at 2:55 PM Simon Josefsson <[email protected]> wrote: > > Andrew Lee <[email protected]> writes: > > > Hi Otto, > > > > On Mon, Sep 7, 2026 at 12:54 PM Otto Kekäläinen <[email protected]> wrote: > >> Personally I feel it does not make sense to me to have all Go > >> libraries to change the source package name on every new major > >> version, so I find it hard to judge whether the implementation details > >> of it make sense or not and thus I don't think I should review it. > > > > I understand your concern on the source package rename part. However, > > this is similar to how we bump SONAME for C/C++ libraries, which also > > requires going through the NEW queue for each bump. > > But only for the NEW binary package. The Debian source package name > does not change with C/C++ soname bumps. > > I agree that we should use golang-*-vX-dev consistently. I went through > many different ideas that I thought were better until I arrived at this > (and made several confused posts about this to list many months ago..). > > I'm less confident that renaming all source packages is needed or a good > use of our time... I won't object if anyone else does it though, but I > don't envy the task. I think renaming binary packages could be > sufficient, and adopting the new source package name style could be > opt-in going forward for new packages or API versions. > > /Simon -- -Andrew
