Opinions on the "statically-linked-binary" Lintian check

[Emanuele Rocca <ema@debian.org>]

Hi folks,

Lintian has a check called "statically-linked-binary", raising an error
if a package ships statically linked binaries or object files.

Historically, programs written in golang have been explicitly excluded
from the check. However, I recently noticed that the Lintian code
considers an ELF file to be dynamically linked if it has at least a
NEEDED entry, or INTERP. By default, executables produced by the golang
compiler have both, and thus are not considered to be statically linked.
For this reason, I proposed dropping the code that explicitly excludes
golang programs:
https://salsa.debian.org/lintian/lintian/-/merge_requests/613

Nilesh (in CC:) raised the good point that golang packages built without
CGO by setting CGO_ENABLED to 0 end up producing actually-static
binaries. One such example is certinfo, here's the output of `file`:

 /usr/bin/certinfo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=9bd011908397de597d121bd82d6de9f5ff47273b, stripped

By removing the code that excludes golang altogether from the check,
those would be flagged as errors by Lintian. Is there a good reason to
disable CGO and have a fully statically linked binary? Would it be
useful to have Lintian flag this? More in general, what is your opinion
on this Lintian check? Is there any value in having it for golang
packages, or should we exclude golang altogether?

Thanks!
  Emanuele