new selftest target in debian/rules, new package state for autobuilder (suspect), debs that selftest on build
Hi,
I'm trying to build gcc-3.0 manually because the autobuilder on m68k
just timeout on it. So all this takes gcc-3.0 as example, nothing
personal. This is more about improving the autobuilders.
Doing a test compile on i386 (way faster to check build-depends and
general errors there) I noticed that the selftests of gcc had
unexpected failures.
But since that happens all the time the results of the selftests are
just ignored and the build succeeds. The reason being that otherwise
there would never be a successfull build, esspecialy for the MHz
challenged archs.
But neigther failing nor succeeding seems to be right here.
My suggestion would be to have a target "selftests" in
debian/rules. During build that should be called to carry out the
selftests (if any).
Now two things can happen:
- The selftests work fine. The package completes its build and gets
uploaded to unstable. (the build succeeds).
- The selftests fail. The package gets flaged as suspect because of
selftest failures and uploaded to experimental or selftest-failures or
so. Then someone can take a look at the debs and check what caused the
selftest failures. If its nothing serious (like outdated testcases)
the package can still be released. If its something serious, he can
patch it and upload a new version.
Why not just fail the build when the selftest fails?
Many packages build multiple debs. Many take very long to build,
esspecially those with selftests. A selftest failure in for example
the libjava portion of gcc should not hold back all other gcc
packages. The debs should still be build and then the maintainer can
move everything but libjava.deb to incoming.
Comments, ideas, flames?
Goswin
Reply to: