Re: Results of the Bootstrap/Crossbuild Sprint
On Mon, Sep 22, 2014 at 09:14:58PM +1000, Brendan O'Dea wrote:
> As the upstream and maintainer of help2man, I figured that I should
> chime in here.
Thanks!
> The recommended use of help2man is that it should be run by the
> maintainer, and should not need to be run by the end user unless they
> have made changes which have touched the dependencies of the manual
> page. This is similar to autoconf, makeinfo, etc. where the products
> are typically included in the distribution tarball.
This doesn't make any sense to me. In general, we want to rebuild things
from source. We have suffered long enough from outdated configure
scripts and are generally switching to dh_autoreconf (i.e. running
autoconf during build). In a similar vein, many packages run makeinfo
and of course help2man during build. help2man has more than 200 reverse
Build-Depends! Are you sure that all of these packages are using
help2man in a wrong way? Maybe that's a communication problem (or a
flawed recommendation)?
> The sprint doc (https://wiki.debian.org/Sprints/2014/BootstrapSprint)
> seems to suggest that coreutils, bison and flex require help2man at
> build time.
Yes, all of them do. corutils is a bit special as you figured out.
> Note that the only reason that help2man is not arch:all is that it
> includes a preload kludge to support building localised manual pages
> using translations from the build tree rather than /usr/share/locale.
Whether help2man is arch:all or arch:any is almost irrelevant to
crossing, because it is mostly a build-tool being marked M-A:foreign.
> My recollection is that coreutils at least doesn't use this behaviour,
> and in fact includes a copy of help2man in the source distribution so
> should not require a build-dependency at all (disclaimer: I've not
> looked at the Debian packaging).
Indeed, coreutils has its own copy of help2man. From a cross-builders
pov, it does not matter whether coreutils embeds or uses help2man: Both
variants make it fail to build.
> The recommended use is not actually to include the program in the way
> that coreutils does, but to use the "missing" program from automake
> (see "Using help2man With make" in
> http://www.gnu.org/software/help2man/) which should allow the program
> to build, but use the version of the manual page included in the
> source (which may be out of date).
If this is the case, then the detection logic in autotools is critically
flawed. It should automatically use "missing" for help2man when
cross-compiling. At the moment though, it figures that help2man is
available and thus can be used.
So where do we go from here? The one thing that's a fact, is that bison,
coreutils and flex all fail to cross-build and that the step at which
they fail involves help2man. Very likely more of those 200 packages
mentioned above are affected (but not all of them have to be cross
buildable). Finding a solution that works in general is highly
desirable.
Helmut
Reply to: