On Mon, Nov 19, 2012 at 10:07:40AM -0700, Bdale Garbee wrote: > Is there some reason you're ignoring the package's existing test suite? > > While I hadn't been paying attention to it, now that I've read about it > I certainly don't object to the concept behind dep8. But it makes no > sense at all to start creating separate tests when the upstream package > source already includes a credible test suite, as is the case with gzip. > The current gzip debian/rules file invokes the test suite using 'make > check' and the package build will not complete if any of the tests fail > on the as-built executable. > > So, I'm not interested in merging this patch as-is. If it can be > reworked to run the existing test suite on an autopkgtest testbed, then > I'd be willing to merge such a patch. If that's not possible, then I > suggest the design of autopkgtest be revisited so that we don't need to > replicate and/or diverge from upstream test suite creation and management.
It's definitely possible. autopkgtest is an interface to run a testsuite and declare its presence. But a specific autopkgtest test can do whatever it wants, including chain-running upstream test suites. In fact, while I can't speak for Ian :-), I think autopkgtest has been designed precisely with that flexibility in mind. In this specific case, while I don't see anything wrong with adding some ad-hoc autopkgtest tests (which seem better than no testing at all!), I agree with you that running the upstream test suite would be even better. Cheers. -- Stefano Zacchiroli . . . . . . . [email protected] . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
