Hi Mike, 2017-09-29 2:59 GMT+02:00 Michael Stone <mst...@debian.org>: > On Fri, Sep 29, 2017 at 12:45:57AM +0200, Manuel A. Fernandez Montecelo > wrote: >> >> I was thinking of preparing an NMU for this, help2man issues are very >> annoying to (re)bootstrap ports. >> >> Michael, do you have any preference about how the solution should look >> like? Or would you reject a NMU at all? > > > I'd rather have a standardized build option to skip the documentation than > something that sometimes builds man pages that don't match what's being > built. In dreamland I think an even better option would be a mechanism > (maybe in dpkg-buildpackage?) to set a build flag indicating that this > should be a minimal build for bootstrapping (skip anything that needs to run > natively or that might otherwise cause problems) and automatically sets the > version string to something indicating it's a less-than-complete package. > Putting some kind of unique hack or magic side effect into dozens of > packages seems like a less-than-optimal solution.
Looks like you're describing the existing mechanism of build profiles. Some modifications might be needed depending on the package, though, since the upstreams are not always ready to cross-build cleanly, e.g. like Eleanor's patch, which is quite simple. What upstream is trying to do in this case it cannot ever work in any cross-compilation scenario [*] -- to invoke the program built in a foreign arch to extract "--help" and dump it in a file. [*] unless the foreign binary is interpreted with an emulator automagically, or similar tricks. So as it is, it's a kind of bug upstream, perhaps the proposed patch can be applied there too (I can do it). I think that attemping to solve in other ways proposed has more drawbacks than benefits. For example, if using the system's coreutils binaries, it's not guaranteed that the version is the same (one could be crosscompiling packages from unstable in stable), so the output is not guaranteed to be correct anyway, and one creates a self-dependency cycle. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
