Hi Otto, On Sun, Sep 13, 2026 at 4:39 PM Otto Kekäläinen <[email protected]> wrote: > In both cases the -v2 package was pulled in as an indirect build dependency.
A quick way to trace where the wrong dependency cames from in the build environment: `apt-rdepends -r <package-name>-v2-dev.` > Explicitly depending on the v0 versions by adding > golang-github-dlclark-regexp2-dev and > golang-github-alecthomas-chroma-dev respectively solved it. Glad to hear that fixed the issue for trufflehog and glow. > I don't know which indirect dependency incorrectly has the wrong > relation to a too new version, but explicitly depending on the v0 > versions fixed it for Trufflehog and Glow. I will finalize the changes > and upload tomorrow. In legacy GOPATH mode, we did not check go.mod import paths strictly. People often relaxed API version rules and disabled upstream tests as long as the package did not FTBFS. Because of this, many legacy packages still have such GOPATH hacks in their dependencies with tests disabled in debian/rules. With module-aware builds in `dh-go`, we followed upstream's expected import paths to place files from -dev packages on the filesystem. This simplifies maintenance and improves build-time dependency checks. And upstream may easily reproduce if issue we have on Debian side. I know renaming source and binary packages to match the real import path takes extra work now, but it brings huge long term benefits for the Debian Go ecosystem. I really hope you may understand it and support with this approch. Best regards, -- -Andrew
