DEP8 tests using the built package source

[Martin Pitt]

Hello Stephen,

Stephen Kitt [2014-03-25  0:45 +0100]:
> > Recent versions of autopkgtest now ship the new
> > /usr/share/doc/autopkgtest/README.running-tests.gz which I hope
> > explains the use cases and how to run them.
> 
> It does explain the various use cases, but I found auto-package-testing more
> helpful in that it contains the actual launcher scripts (prepare-testbed and
> run-adt-test) used on the CI platforms.

Indeed these are still what we use in production for i386/amd64. For
armhf and ppc64el we already use the new adt-virt-lxc and adt-run
directly, and that's what we want to move to next cycle, too. I'll
have a meeting with Antonio (http://ci.debian.net) tomorrow to discuss
the next-gen architecture, for sharing this between D and U.

> > > I'm wondering how all this meshes with Ubuntu's "fast migration" approach:
> > > I'm guessing it doesn't see build-time tests which are run as part of the
> > > build... 
> > 
> > It kind of does by rejecting packages which don't build on all
> > platforms, i. e. if tests during build fail on a particular arch.
> 
> Right, I was thinking of the positive side; as I understood it there is some
> sort of bonus in the "proposed" migration in Ubuntu for packages with working
> autopkgtests.

Not really a bonus as such. The condition is that for a package X
upload, the tests of X and all tests of X's reverse dependencies have
to succeed, otherwise it doesn't propagate. If there are no tests, the
package still propagates once the other conditions are met (built and
installable on all arches).

> If that is correct then it would be better to use tests during the
> build and also as autopkgtests, wouldn't it?

It's better to have both kinds of tests, yes. They don't necessarily
need to be the same (and in most cases aren't). They have a different
scope and purpose.

> That's what I liked about DEP8 at first — it helps avoid brown-bag errors ;-).

That too :-) But I mostly value them for avoiding the introduction of
ABI changes or otherwise changed behaviour which break existing
packages. E. g. if we upload a new pygobject which breaks our
graphical installer (ubiquity), we'd hold pygobject instead of
noticing the breakage in the release two weeks afterwards, which is
how it should be.

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/20140325/d3c60fda/attachment.sig>