Nilesh Patra <nilesh@riseup.net> writes: > On 08/11/24 14:29, Simon Josefsson wrote: >> For some reasons I had a look at the golang-ed25519-dev package in >> Debian and wanted to understand who used it (since it is obsolete), and >> noticed that 'riseup-vpn' referred to it in Build-Depends but at some >> upstream release it must have stopped using it. There seems to be no >> references to that library namespace in the latest current release. So >> rebuilding the package without that Build-Depends works fine, and I did >> an upload of 'riseup-vpn' to reduce the number of build-depends of >> golang-ed25519-dev. > > I am the maintainer of riseup-vpn. Thanks for the upload! > > However this seems like a generic problem, and I worry that there > is a >> large number of no longer necessary Build-Depends for Go packages. >> Is that the case? > > Unfortunately yes. Not too long ago I even noticed that in some > of the packages there's a "Depends" on golang-github-stretchr-testify-dev and > there's no reason for any developmental package to depend on a testing library. Detecting that requires some human knowledge, I think... but I've seen similar things where Depends packages are not necessary for the actual installed /usr/share/gocode files, but may have been necessary as a build-depends. There is no go.mod or go.sum in /usr/share/gocode, so I'm not sure how to automate discovering such problem. > Some of it was because dh-make-golang would add it into depends. I don't know > if that's still the case. My perception is that almost everything from build-depends is mirrored in *-dev's depends, but that may be wrong. >> Thoughts? > > I suppose the problem you point out is not specific to just the go team but > a number of other packages in the archive as well. Simply because it's hard > to keep track of every single build-dependency and evaluate before upload. Indeed and good point -- this is not a Go-specific problem. > It is unsurprisingly more common for more complicated packages (as you saw in > riseup-vpn). > >> Are there any tools or linters to discover possibly no longer relevant >> Build-Depends for Go packages? Any thoughts on how one could be >> created? It could be a lintian plugin, so every packager will notice >> it, but maybe it is too difficult to write one for lintian. A salsa >> pipeline job is another idea. > > As Shengjing pointed out in other thread, dh-make-golang needs volunteers and > is not maintained in the best shape. We discussed at this debconf about another > tool that Maytham wrote called https://tracker.debian.org/pkg/gophian > > It may be worth to add in some logic (parsing go.mod) to spot out redundant > build-dependencies. It'd be similar to a linter you propose. Alas I'm not knowledgeable enough about Go to have good grasp how to improve anything here. /Simon
Attachment:
signature.asc
Description: PGP signature