implicit debian/tests/control files

[Martin Pitt]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20140912/5b34761c/attachment.sig>