On Wed, 2026-05-06 at 20:54:05 +0200, Simon Josefsson wrote: > I think that's an opinionated preference: the risk of having obsolete > stale man pages is considerable, especially for fast-moving packages > which often is the case for Go packages. This is a subjective > maintainer decision, so up to you. Although it seems a bit weird to now > have a mostly help2man-generated static file shipped, which begs the > question if the file is the preferred form of making modifications to.
If by opinionated preference you mean not wanting to cause cross-building failures, or not wanting to introduce packaging complexity to avoid those, then I guess? > The best is indeed if you can convince upstream to accept to ship a man > page, then you don't need a Debian-specific hack. I've had success with > several packages for this. I think using an easier markup language might go some way with trying to convince them. For a Debian specific patch I'd just go with Perl's POD which is extremely easy to write in and requires no additional build dependency. If you prefer the keep using help2man, a better/simpler way to integrate that w/o breaking cross-building, is to make it a maintainer only manual target (in debian/rules) to refresh the man page, where it would also store the output of the program program --help, and during normal (non-cross) builds it would compare the --help output with the one kept on record during the last new upstream release (which can be run fine as we are not cross-building), and if they differ it would fail the build, which should only happen during new upstream update, where the maintainer would refresh the man page. Ideally help2man would be able to work from a file with the program's --help output, so I'll file a wishlist for that upstream. So the above could be even easier to implement. Thanks, Guillem
