Checking for packages being built twice.
In case someone it looking for an easy QA task, here is some suggestion:
Search for packages that are configured or built twice in the buildds.
Theory: The buildds first build the software my telling the debian/rules
makefile to create the target "build" (hopefully in some future
"build-arch") and then to create the packages by telling make to create
the "binary-arch" target using the rules from debian/rules.
The main reason to seperate those is that the latter needs fakeroot (or
real root or whatever) while the former does not.
As the "binary*" targets should also work without having called any
"build*" target before, they have to list those as prerequisites.
Thus when the binary target is to be done, make checks the those
prerequisites are up to date. If there is any phony target (i.e. not
creating the target as actual file) in the prerequisites of the build,
make has to rerun those targets, rerunning configure and make again.
Impact: I guess this is a rather low-profile thing. The impact of those
bugs is a little more time spent by the buildds and the theoretical
danger of the second build being garbled by the fakeroot they run in.
(Fakeroot works by setting some LD_* variables, which some build scripts
might incorporate, creating invalid binaries).
Required action: I see no way to check this in lintian (except when this
actually garbled something), as lintian sees only the generated packages
and not the log files. So I think the only way to find those is looking
at the buildd logs for logs that run configure or a compiler after the
invocation of the "debian/rules binary-arch", which should be an easy
task if someone is desperately looking for some QA task to do.
More complicated would be to find packages which do not call configure
or a compiler twice, but only run make (without install) a second time.
(Though this has even less impact).
Hochachtungsvoll,
Bernhard R. Link
P.S: if you find such behaviour in your own package, please fix properly
and do not add new bugs: The fix is usually not to remove prerequisites
(unless they are clearly unecessary, though that is unlikely) but to
make sure make can check it is already done. For example:
build-arch: build-arch-stamp
build-arch-stamp: patch
$(MAKE)
touch build-arch-stamp
with patch a phony target will make it call make twice. The fix is not
to move the "patch" prerequisite elsewhere (as it is a prerequisite, or
do you prefer if the source if first compiled and then patches?) but
to make sure it is not phony, i.e. either the patch rule creates a file
"patch" after successfull operation, or you make a target prerequisite
that does so (might be called patch-stamp, $(QUILT_STAMPFN) or wherever
you got your patch target from).
Reply to: