On Wed, 31 Jul 2024 at 19:01:05 +0500, Andrey Rakhmatullin wrote:
> On Wed, Jul 31, 2024 at 09:46:27AM +0100, Simon McVittie wrote:
> > 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.
>
> I always thought the smoke test is redundant if there is the upstream
> tests one.
> What do you think?
I think it is not redundant, because it's a quick way to catch packaging
errors where the python3-foo binary package is missing a mandatory
dependency - which seems to be a somewhat common failure mode, because
the maintainer (who presumably has the Build-Depends installed) will
never notice it by testing on their own system.
For instance in this (hypothetical) package:
Source: python-foo
Build-Depends: dh-python, python3-all, python3-bar, ...
Package: python3-foo
Depends: ${misc:Depends}, ${python3:Depends}
Suppose python3-foo does an "import bar", therefore there should have
been a "Depends: python3-bar" which is missing here. The smoke test
would detect that.
(I know that ideally python3-bar would be part of the ${python3:Depends},
and with some upstream build systems under some phases of the moon,
it is; but I'm thinking here about the packages where that information
doesn't work or isn't propagated.)
I'm a fan of putting a small amount of effort into automated tests, and
then having running the tests before uploading save you from a class of
Severity: grave bugs forever :-)
> > But I don't think we can easily have that, because the Testsuite field
> > only takes one value.
Actually it seems it's meant to be able to take more than one value, and
the fact that autodep8 doesn't support that appears to be considered a bug.
(#1042717, #1061620, #1077645)
smcv
