Le sam. 12 avr. 2025 à 18:13, Simon Josefsson <[email protected]> a écrit :
> Otto Kekäläinen <[email protected]> writes: > > > Hi! > > > > After assessing pros and cons, I decided to stick with the `go mod > > vendor` -> debian/vendor/ approach. See example in > > https://salsa.debian.org/go-team/packages/usql/-/merge_requests/1 and > > specifically commit > > > https://salsa.debian.org/go-team/packages/usql/-/merge_requests/1/diffs?commit_id=60a45c4e5e18b89c297b6cb6adf62115041a9d8b > > > > Having them downloaded separately with uscan would pull in a bunch of > > extra binary test files and whatnot those repositories have. > When running `go mod vendor` only the files really needed for the build > are > fetched, and the file/directory sizes stay small. There is also less > > work to maintain d/copyright and d/source/include-binaries. Not using uscan makes it very non-standard, and impractical, in the long run. Use Files-Excluded-<component>, see for example https://sources.debian.org/src/node-yarnpkg/4.1.0%2Bdfsg-1/debian/copyright/#L22-L42 Thus all that is regarding copyright maintenance is to be found in debian/copyright. > Using `go > > mod vendor` also pulls in the specific versions defined in go.mod, > > resulting in the most exact and surgically small import. A watchfile > > would encourage to use the latest versions, which may not be the true > > intent. > For now you can pin the version in debian/watch. This could be automated if someone adds support for golang to this uscan option: ctype=golang (only perl and nodejs are implemented now). Jérémy
