[Piuparts-devel] simplifying running piuparts

Didier 'OdyX' Raboud odyx at debian.org
Tue May 21 13:34:54 UTC 2013


Le mardi, 21 mai 2013 14.58:17, Andreas Beckmann a écrit :
> >> On Tue, May 21, 2013 at 12:05 PM, Holger Levsen <holger at layer-acht.org>
> > wrote:
> >>> have an option to run piuparts automatically by debuild, after or
> >>> before lintian.
> 
> that means we need a driver script that accepts a .changes file and
> creates a local repository and runs piuparts package by package

That sounds like a plan.

> >> Also integrate it with git-pbuilder/pbuilder/cowbuilder to run
> >> piuparts inside the created clean(ish) chroot, so it's less time
> >> consuming.
> 
> does not easily work for upgrade tests from testing or stable

Indeed. But testing that the packages install, upgrade, remove and purge 
correctly on top of the previous versions from unstable is already a good 
indicator.

> > Actually, doing it in sbuild (and hence hypothetically on the buildds)
> > would be awesome:
> >  - deinstall build-depends
> >  - install previous version (+ dependencies),
> 
> that part might fail ... but it should abort and *not* fail the test (to
> fix the broken (uninstallable) package in sid)

Indeed, didn't think of that use-case.

> > A failure at each of these stages could fail the build.
> > 
> > (The problem becomes tricky with source packages building mutually-
> > incompatible binary packages).
> 
> Only for passing the .changes to piuparts.
> If we create a driver script that takes a .changes, creates a local
> repository and runs piuparts on each built package in turn, this will
> work well. (It will require the arch:all packages to be available if
> this was a binary-only build)

The .changes file doesn't have the arch:all packages, but they might indeed be 
dependencies of binary packages. I suspect that the fact that buildds have 
access to incoming.debian.org could facilitate this step though.

> I consider the package-by-package testing as a much better test than
> installing all the packages at once because it can discover much more
> dependency issues - and it much closer resembles what is being run on
> piuparts.d.o

Sure. I just tried the --run-piuparts option of sbuild on on of my packages 
(lsb) and it failed miserably for that very reason.

OdyX



More information about the Piuparts-devel mailing list