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