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

Re: libssl in golang-github-google-certificate-transparency



Otto Kekäläinen <otto@debian.org> writes:

> Good point! It is easy to add missing dependencies, but there is no tooling
> to spot and remove unnecessary dependencies (and not just in Go but all of
> Debian).
>
> I occasionally read the go.mod diff on upstream important to see what
> changed, but it is all manual.
>
> It would be cool if the dh-golang had some built-in ptrace based thing that
> could say something like "Warning: the package has dependency X defined but
> no files from the package were accessed during the build. The dependency
> can most likely be removed."

I wonder if we could make something automatic and put that into a
Go-specific Salsa CI check?

How about this logic?

- Add new Salsa "build-with-reduced-build-deps' job

- Run 'dh-make-golang check-depends'

- Remove all Build-Depends: that match RM lines

- Use job exit status as inverse of build success - that is, if the
  build succeeded, fail CI because then the maintainer should remove
  those build-dependencies.  If the build fails, then assume it fails
  because the RM'd build-deps were really necessary.

I'm not sure if this would actually be useful, because removing ALL the
RM lines may be too excessive and too often lead the build failures.
Sometimes check-depends propose to RM some that is really needed because
of v2 vs v3 or similar reasons.  Maybe if we could filter those removals
out...  I'll start to manually review the RM lines for some packages
when I make updates and ponder if this make sense or not.

Your ptrace approach may be more feasible...  what would be involved
here?  It has to extract all Go files accessed via open() under
/usr/share/golang during a build, and cross-compare that list with the
files inside each of the build-depends.  If some build-depends provides
files which are never open()'d during the build, then we have a
candidate for removal.  Implementing this sounds a bit more complicated
than my logic though.

/Simon

Attachment: signature.asc
Description: PGP signature


Reply to: