#1149023 dh-go: go.work gets a replace pointing at a directory with no go.mod

Package:
dh-go
Source:
dh-go
Submitter:
Juan Manuel Mendez Rey
Date:
2026-09-25 23:45:03 UTC
Severity:
normal
#1149023#5
Date:
2026-09-25 23:43:46 UTC
From:
To:
In _create_go_work_file, the loop over dependencies that are present on disk
writes a replace directive for any path that exists, and only checks for a
go.mod when the path is a symlink:

    my $filepath = $this->get_buildpath("src/$module");
    next if not -e $filepath;
    if (-l $filepath) {
        next if not -e "$filepath/go.mod";
        ...
    } else {
        print $gowork "replace $module => ./src/$module\n";
    }

A real directory with no go.mod therefore gets a replace it cannot satisfy.
This happens whenever Debian ships only the /vN form of a module: the parent
directory exists because the /vN symlink lives in it, but it holds no go.mod.
golang-github-klauspost-cpuid-dev 2.4.0-1 installs only
github.com/klauspost/cpuid/v2, and something in syft's module graph
(dsnet/compress) requires github.com/klauspost/cpuid v1.2.0, so the build
stops with 124 copies of:

    github.com/dsnet/compress@v0.0.2-0.20230904184137-39efe44ab707 requires
      github.com/klauspost/cpuid@v1.2.0 (replaced by ./src/github.com/klauspost/cpuid):
      reading src/github.com/klauspost/cpuid/go.mod: no such file or directory

Still present in debian/sid at commit 260d81a4525e (2026-09-20).

Checking for the go.mod in the non-symlink branch too would send the module to
the "dummy modules" section a few lines below, which already writes a minimal
go.mod for exactly this case.

I am working around both of these in debian/rules for now, and would rather
not ship that.