Hi all,
I'm interested in making a number of improvements to dh-make-golang, but
want to get feedback/consensus before I invest too much time.
For the first big piece, I want to improve how dh-make-golang calculates
dependencies.
Right now, the `make` subcommand seems to reverse engineer version
control repository roots from `import` statements, then generates Debian
package names from those. I want it to instead use the output of `go
list -m all` (which is what Go uses to build a module) and compare those
module paths to published Go-Import-Path metadata (see
<https://api.ftp-master.debian.org/binary/by_metadata/Go-Import-Path>).
The `estimate` subcommand discovers dependencies differently than
`make`, which I find surprising. It parses the output of `go mod
graph`, which prints the pruned requirement graph. Go does not use this
graph directly; it instead feeds that graph to the Minimal Version
Selection (MVS) dependency resolution algorithm and uses the output of
that to download dependencies and compile binaries. The output of MVS
is available as `go list -m all`. The `estimate` subcommand should do
what Go does and use the output of MVS, not its input, to build a list
of dependencies. And both `make` and `estimate` should share the same
dependency discovery code.
I made a Go module to analyze Go module dependencies:
https://pkg.go.dev/github.com/rhansen/gomoddepgraph
The package-level documentation explains some of the nuances involved.
I would like to temporarily use this module for the `make` and
`estimate` subcommands. Eventually I want to change dh-make-golang to
take an entirely different approach to dependencies; I'll expand on that
in a future email thread once my thoughts have solidified a bit more.
That module currently lives in my personal GitHub account, and it is not
yet Debianized. I would like to open up access to the entire Debian Go
team so that others can easily fix bugs. I could move it to the Salsa
go-team project, but I want it to remain generally useful (not limited
to Debian purposes) and I want it to live beyond its planned temporary
use in dh-make-golang, so Salsa doesn't quite seem like the right home.
Maybe I should just copy the code into a dh-make-golang subdirectory?
Or move it somewhere else? WDYT?
There are several subtasks for this first big piece:
* Revamp dependency graph construction for consistency with Go, as
discussed above.
* Start the long, tedious process of migrating away from the
per-source XS-Go-Import-Path field to a per-binary XB-Go-Module-Paths
field. This would avoid having multiple binary packages simultaneously
claim to provide a particular Go module, which confuses dh-make-golang.
See the relevant TODO notes in
<https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/11>.
There will be a long period when both XS-Go-Import-Path and
XB-Go-Module-Paths are present in a package; the per-binary field will
override the per-source field when present.
* Only consider Debian packages published in new or unstable when
discovering dependencies.
* Do not consider different major versions (/v2, etc.) when locating
a dependency.
* Include version requirements in `Depends` and `Build-Depends` based
on the versions reported in `go list -m all`.
* Do not package multiple modules in the same binary package (see
<https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/11>).
* Even more restrictive: Do not package multiple modules in the same
*source* package (see
<https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/13>).
* More that I'm not thinking of at the moment.
I'll start chipping away at these if there is general consensus.
Feedback appreciated.
Thanks,
Richard
