+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.
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 >
signature.asc
Description: PGP signature
