Re: testing packages at build
On Wed, Oct 08, 2003 at 03:39:58PM -0500, Manoj Srivastava wrote:
> On Wed, 8 Oct 2003 21:09:31 +0200, Bill Allombert <allomber@math.u-bordeaux.fr> said:
>
> > Hello Debian policy, Ancient policy [1] frowned upon running
> > automated check of runtime behavior of packages in debian/rules to
> > save time for the autobuilders, and say that such test should be run
> > by maintainers manually before uploading.
>
> Since this is not in policy anymore, this is not relevant.
So you confirm it has been removed from policy ? Great!
[The full text of my email to debian-policy can be found at
<http://lists.debian.org/debian-policy/2003/debian-policy-200310/msg00028.html>
]
> > I see two possibility to implement this proposal:
>
> > 1°) Let maintainers run tests in the build or binary target.
> > Eventually we add a notest DEBBUILD_OPTION to disable it.
>
> > 2°) We add a test target in debian/rules. Autobuilders will need to
> > be modified to take advantage of this. We can then go farther and
> > implement special testing facility.
>
> > I am sorry for the long post, but I do believe we can make toolchain
> > transitions and release easier with a proper automated test
> > architecture for the autobuilder.
>
> Umm, this is the wrong list. Development issues belong on
> -devel, not on -policy; follow ups set.
Thanks Manoj. It was my plan to move that to -devel once the issue above
was cleared up.
> For the record, flex runs an extensive test suite at build
> time, as do as many of my other packages as I have had time to create
> tests for (kernel-package; the old pkg-order, etc).
>
> If developer routinely add tests to the build option we do not
> need to modify anything. If you can persuade people that adding a new
> target to the rules file is better, we can perhaps have both -- it
> would be easy enough to call the test target from the build target
> itself.
My first goal is to persuade developers that running tests is
worthwhile. For the implentation I have mainly 3 questions:
1) Do porters and autobuilders admins want to be able to skip the tests ?
2) Do we need a more featureful test machinery that just running test
in the debian/rules build ?
3) Do we want to allow for autorecovery ? If gcc -O2 leads to a broken
binary, why not set up debian/rules to automatically retry with gcc
-O0 ?
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
[Please CC me on debian-devel if you expect me to comment]
Reply to: