Niko Tyni [2014-09-11 22:55 +0300]: > > Admittedly these dynamically generated control files are a bit against > > the spirit of DEP-8 to have an explicit test control. However, I think > > it's not too bad as the benefit of not having to change 3.000 source > > packages all the time is just immense. The one thing I'd like to add > > to the source packages is an "XS-Testsuite: autopkgtest" field though, > > so that we can stop maintaining hardcoded whitelists at some point > > (but from my POV it's ok if that takes several years even). > > While I certainly agree about the benefits, I'm worried about other > consumers of debian/tests/control, which would have to reimplement the > implicit control files. There's at least sadt(1) in devscripts that I > know of. Ah, right. From my side I'd certainly like to make this as practical and useful to *you* as the consumers of this. But yeah, sometimes I keep forgetting that adt-run isn't the only implementation of this. See below. > > But as I said, I don't think this should be designed in a hurry. > > Very much agreed; apologies for the premature poking. Not necessary at all, thanks for poking. I should have replied there with my initial thoughts :) > We should have that discussion in the relevant bug report (#759753). *nod* > There's no real urgency, no. We can, and probably should, just stop > including the control files for now and rely on the dynamic ones. Agreed, as long as the dynamic one works it's a lot easier to change centrally. > However, I'm somewhat against including the Testsuite headers without a > debian/tests/control file, as that could actually break other (current > or future) implementations. I think one way to get that "mass-run" effect without breaking the spec would be to use a different XS-Testsuite: value. How about "autopkgtest-auto-perl"? We'd use something similar for "autopkgtest-auto-ruby". Test runners which use another implementation which doesn't provide these would then just not run Perl/Ruby packages, ci.d.n. could just watch out for the additional tags once it updates to autopkgtest 3.5, and we satisfy the spec that "Testsuite: autopkgtest" packages need to have a debian/tests/control. > Similarly, for packages that don't pass their tests and need tuning, > I'd like to add a control file as part of the tuning process even if it's > unmodified from the default one. (We have some additional test-specific > tuning knobs that don't need modifying d/t/control.) Ah, do they work by placing additional config files into d/t/? Whether you want to add the control file is your call of course. As the autopkgtest maintainer I'm pretty much following your needs here (and just moderate a bit to ensure that it doesn't collide with other goals/robustness/etc.). Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Attachment:
signature.asc
Description: Digital signature