Dear Toddy and list, On Sat, Jul 11, 2026 at 7:06 PM Dr. Tobias Quathamer <[email protected]> wrote: > I've just seen the same error with the package "age". It can also be > resolved by using "dh_auto_build -- filippo.io/age/...".
Let's provide some examples for others to test their package in experimental with new dh-golang in module-aware builds, so that they can see the issues and join this discussions. Here are my examples, you may do the same to see if your packages builds in module-aware builds dh-golang in experimental: https://salsa.debian.org/go-team/packages/pocketbase/-/tree/debian/experimental?ref_type=heads https://salsa.debian.org/go-team/packages/goxkcdpwgen/-/tree/debian/experimental?ref_type=heads > The FTBFS seems to occur because those packages do not specify > "package main" in the top-level directory. Both packages have their > "main" package in a subdirectory. > > I suspect that the current dh-golang approach is to build the "main" > package from the toplevel directory, so usr/bin is empty if there's no > main package to build. > > By using the three dots, you instruct the go compiler to recursively > cycle through all subdirectories, where it finds and builds the "main" > packages. If I understand it correctly. The dh-golang in the old legacy GOPATH mode behaves to always append /... by default, so that we have to use DH_GOLANG_EXCLUDES to avoid bringing extra budil-depends from examples or tests. And under new GO111MODULE=on mode, dh-golang only run a `go list` routine to resolve "main" modules from the toplevel directory, so that all the submodules got lost in it's `go list` without append /... by default. > I'm wondering if we can just submit the value from "XS-Go-Import-Path" > to the building step of dh-golang? Or would that have any negative > consequences? I am not sure if I understand it completely here. Do you mean maintainer has to submit multiple values in "XS-Go-Import-Path", so that the compiler will lookup and builds all of the values from "XS-Go-Import-Path" as "main" packages? The consequences for append /... recursively by default or not: If we don't instruct the go compiler to recursively cycle through all subdirectories. The build behavior gets changed in many packages, and maintainer has to append the workaround in previous mail manually. Or maybe need to add main package manually into "XS-Go-Import-Path". If we add that by default. It behaves the same like in GOPATH mode. So maintainer probably don't need any extra changes and their package builds. I don't see the negative consequences for append that by default as we already have DH_GOLANG_EXCLUDES to avoid building unattended binaries and avoid bringing extra budil-depends. Maybe we have to test to enable module-aware builds on more packages in experimental then. Best regards, -- -Andrew
