[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Using debian/vendor/ in Go packages?





Le sam. 12 avr. 2025 à 18:13, Simon Josefsson <simon@josefsson.org> a écrit :
Otto Kekäläinen <otto@debian.org> 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


Reply to: