On 7/19/26 5:03 PM, Reinhard Tartler wrote:
I personally find patching the source packages preferable, but for practical reasons, having dh-golang produce "helper" modules (dummy requires) as you suggest workable.
As mentioned in the sprint meeting, I think having a option to enable it in debian/rules would be best - it don't generate go.mod magically, but we don't need to maintain a patch for this as well.
Other option would be to try what Andrew suggested - using GO11MODULES=auto
do we have an idea how many packages are affected by this? -rtOn Sun, Jul 19, 2026 at 1:02 PM Mathias Gibbens <[email protected] <mailto:[email protected]>> wrote:Hi all, We've got several existing Go packages that don't have an upstream go.mod file. But now with module-aware builds, we must have a go.mod present for things to properly work. One approach could be for dh-golang to generate a stub go.mod automatically during the configure stage if Go code is present in a top-level or first-level directory but there's no go.mod. This might be a bit "magical" as a source file would be injected during the package build whose origin might not be obvious. Alternatively, we could add a patch to each affected package that creates the missing go.mod file. The advantage here is that it's more clear where the go.mod file comes from, but is likely much more work- intense, with each affected packaging needing manual attention. Is there a group consensus on which approach to take? Mathias -- regards, Reinhard
OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
