On Mon, 29 Jul 2024 at 18:55:26 +0500, Andrey Rakhmatullin wrote:
> On Mon, Jul 29, 2024 at 03:30:39PM +0200, PICCA Frederic-Emmanuel wrote:
> > My use case, is to check that all the Dependencies computer by dh_python3
> > from the build tools are indeed listed in the Depends of the binary package.
>
> Maybe we indeed want a "minimal" autopkgtest environment
For a simple smoke-test that the Python packages import succesfully, isn't
this exactly autopkgtest-pkg-python?
For thorough test coverage, I don't think this is possible: in general,
the test suite will legitimately require installation of packages that are
only needed during testing (pytest or similar), or packages that are
optional for basic use of the code but mandatory for full test coverage
(those might be Recommends or Suggests).
> but many
> upstream tests will fail in those and I don't see an automatic way to test
> a random package in this way
If we want to run upstream test-suites as autopkgtests, then I think
ideally we want the same test coverage as autopkgtest-pkg-python,
*and* the same test coverage as autopkgtest-pkg-pybuild, as separate
autopkgtest test-cases with different dependencies.
But I don't think we can easily have that, because the Testsuite field
only takes one value.
Would it be possible to make autopkgtest-pkg-pybuild absorb
the functionality of autopkgtest-pkg-python, so that it
generates a debian/control that does some simple smoke-tests (like
autopkgtest-pkg-python does), *and* runs the upstream test suite (like
autopkgtest-pkg-pybuild currently does)?
If not, then the proposed policy change would result in us gaining
coverage but also losing coverage.
smcv
