You can tell pbuilder to include extra packages in the environment by
setting the EXTRAPACKAGES variable. In my .pbuilderrc I have something like:
PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi"
case "$TEST" in
ffmpeg) # For testing of WinFF
EXTRAPACKAGES="ffmpeg debfoster ${EXTRAPACKAGES}"
*) # Fast testing
EXTRAPACKAGES="${EXTRAPACKAGES}"
;;
esac
I am at this moment not sure if I needed the first line for this to
work, but now I can run pdebuild like so:
$ TEST=ffmpeg pdebuild
Paul
Ben Finney wrote:
> Howdy mentors,
>
> Why does 'dh build' attempt to run the package's test suite, but
> doesn't satisfy the run-time dependencies before doing so? How can
> this be made to work within a pbuilder environment?
>
>
> I'm packaging a Python application that has a unit test suite. This
> unit test suite, naturally, imports each of the modules in the
> application in order to test them. That, in turn, causes any of the
> 'import bar' statements in the application to be executed. So, the
> unit test suite will fail in the absence of any one of the package's
> Python library dependencies.
>
> Yet, when I attempt to 'pdebuild' this package, it runs the 'build'
> target of 'debian/rules', which runs 'dh build', which runs
> 'dh_auto_test', which runs the application unit test suite. At this
> point in the process, though, the pbuilder environment does not have
> the package dependencies installed, so the unit test suite fails,
> failing the 'pdebuild'.
>
> Running 'debian/rules build' shouldn't need the package dependencies
> installed, because the package isn't being installed yet, only built
> into a Debian binary package. So why is the package unit test suite
> run from 'dh build'? Isn't this going to be a problem for every
> package that has a unit test suite?
>
>
> One possible response would be to list every run-time library
> dependency as a build dependency, but that seems ludicrous; those
> libraries aren't needed to build the package, they're only needed when
> running the application (whether under test or not).
>
> Another possibility would be to suppress the 'dh_auto_test', but I
> don't want to change the way debhelper operates without a very good
> reason. So far all I have is the fact that it's getting in my way, but
> that could well be my fault.
>
> How is this supposed to work?
>
Attachment:
signature.asc
Description: OpenPGP digital signature