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. In the Golang world, the Major API Version acts like a C/C++ SONAME. Upstream usually maintains multiple major versions at the same time, and they live in different import paths. I can easily got some benifits with versioned suffix for the package in my mind: * Multiple Version Co-Existence Possible: when go.mod contains same module in different path or versions. * Clear Package Naming: Matching the package name with the upstream import path follows our naming convention and avoids confusion. * Easier Package Queries: It makes it simple to query whether a specific Go import path is already packaged in Debian. * Identical Build Paths: Building with the exact same import path as upstream ensures we can receive upstream support. * Easier Debugging: Different path will be packaged in different package. It makes it easier to reproduce and debug issues on both upstream and Debian environments. more...etc I know it requires passing through the NEW queue for echo major version bumps, and it matches how Debian handles library ABI transitions. Best regards, -- -Andrew
