On 3/2/26 03:33, Simon Josefsson wrote:
+1 on general effort. I didn't see you mention the following aspect
(maybe I missed it), but I would find a command 'dh-make-golang
refresh-depends' that I can run after a version upgrade of an existing
package. It would make modifications to the Build-Depends/Depends
lines, but be clever enough to not kill manual changes. This could be
implemented in a number of ways, not sure which is the simplest to do.
I didn't mention `refresh-depends` because I hadn't looked at that code
yet, but I definitely want to include it in my improvements. I'll try
to make any changes I make to `make` be reusable for `refresh-depends`.
I'll probably start with `estimate` because that's the least risky to
change, then move on to `make` and `refresh-depends`.
-Richard
What I manually do is this:
dh-make-golang check-depends > ../foo
gbp import-orig --uscan
dh-make-golang check-depends > ../bar
diff -ur ../foo ../bar
and review things manually. However, I make a mistake or forget to do
this for one version upgrade, unnecessary Build-Depends will be forever
present in debian/control.
/Simon
Richard Hansen <[email protected]> writes:
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
