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.
Some of it was because dh-make-golang would add it into depends. I don't know
if that's still the case.
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.
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.
I don't recall seeing this concern discussed in the go packaging team
documentations, but pointers welcome.
Thanks for bringing this up!
Best,
Nilesh
