Hi Juan,

On Wed, 2026-04-29 at 00:34 +0000, Juan wrote:
> 1. Regarding the correction on dh-golang, then I understand that it
> copies files to builddir rather than creating symlinks, and that
> DH_GOLANG_INSTALL_EXTRA is the mechanism for go:embed. Is that
> correct?                                                                      
>                                                                               
>                                                     

The way that the dh-golang tooling works is that it will copy all *.go
files (and some others like go.mod, go.sum and any testdata directories)
to the build directory (which is the value of the --builddirectory
option passed to dh in debian/rules, usually "_build" or
"debian/build"). Then it will run `go install` in GOPATH mode, which
will use packages from /usr/share/gocode/src rather than downloading
them from the internet as go tooling usually does. Following this, there
is different handling for installing library code (golang-*-dev
packages) and binaries (for end-user programs such as syft).

As I've mentioned before, only *.go files and some others are copied,
not everything. This means that if any other files are needed (e.g. test
data in directories not named "testdata", or, as in your case, files
referenced by //go:embed directives), they must be copied into the build
directory as well. This is achieved by passing them to
DH_GOLANG_INSTALL_EXTRA. So yes, this will solve the problem you're
having, but no, this is not specific to go:embed.

> I intend then to migrate syft to dh-golang. Before doing so, could you
> clarify:   should I first unvendor the ~210 dependencies already
> packaged in Debian (adding them as Build-Depends), or is it acceptable
> to use dh-golang with the full vendor/ directory and -mod=vendor for
> now?

The target is to not vendor anything and rely only on libraries that
have been packaged in Debian. There are circumstances where partial
vendoring is acceptable, but this is very narrow. Either way, complete
vendoring isn't acceptable, at least dependencies that have been
packaged need to be used instead.

I've already started going through syft's remaining unpackaged
dependencies and packaging some of them. I'll let you know how far I
get.

--
Maytham

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to