Re: testing packages at build
On Thu, Oct 09, 2003 at 10:59:13AM -0500, Manoj Srivastava wrote:
> On Thu, 9 Oct 2003 14:15:03 +0200, Bill Allombert
> <firstname.lastname@example.org> said:
> > 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 ?
> i) This would, indeed, depend on the tests; if the tests take
> 4GB of ram and 48 hours, then thay are probably
I assume you won't mind applying common sense here ?
> ii) However, not having the tests run by default would greatly
> reduce the benefit of having the tests in the first place
> iii) I haven't heard about any repurcussions on the buildd's from
> having to run the tests in gcc, flex etc, so are you sure this
> is required?
Not being involved in the autobuilder process, I wanted to
gather input from porters before reaching any conclusion.
At this stage, I don't think it is required, unless maybe by
the maintainer. Maybe an optionnal 'notest' DEB_BUILD_OPTIONS can be
more than sufficient to handle this case.
> > 2) Do we need a more featureful test machinery that just running
> > test in the debian/rules build ?
> I think this is the wrong question. Sounds like a solution
> begging for a few use cases. We already have packages that do run
> time tests; and language infrastructures like Perl already have tests
> harnesses; before we go about speculatig about designing yet another
> testing harness we should have a good, solid set of use cases that
> require such machinery.
From comments from you and others on the list, I see that quite a
number of tests are already done with the current machinery, more
that I was expecting, so probably we don't need another interface.
> > 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 ?
> I think this is a bad idea. How many successful auto recovery
> mechanisms have you seen in the wild? If they are so rare, why are we
> debating standard practices and policy based around such vapour ware?
Are we ?
Well, I have a package (pari) with the bad habit of triggering
optimisation error on at least one architecture (it was ARM last time). I will
implement that for the sake of the experiment.
Imagine a large red swirl here.
[Please CC me on debian-devel, thanks]