Package: ftp.debian.org,autopkgtest
Severity: normal

According to a recent addition to
<https://ftp-master.debian.org/REJECT-FAQ.html>:
> Tests, including autopkgtests, are part of our build process. Packages
> in Main can only require packages in Main to run their tests (both
> build time and autopkgtest). Downloading unpackaged programs, depending
> on contrib/non-free packages, etc. are not acceptable for Main. We are
> just adding this now as it turns out this wasn't nearly as obvious to
> some of you as it was to the FTP Team.

This seems somewhat inconsistent with the design decision that
autopkgtests are allowed to assume that Internet access is available:

<https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst>
> In general, tests are also allowed to access the internet. As this
> usually makes tests less reliable, this should be kept to a minimum;
> but for many packages their main purpose is to interact with remote
> web services and thus their testing should actually cover those too,
> to ensure that the distribution package keeps working with their
> corresponding web service.

This text was added after I proposed a "needs-internet" restriction in
#851556, and was told that such a restriction was unnecessary because
the designers of autopkgtest intended that all tests may assume they
have internet access.

Do the ftp team make a distinction between tests that download and
execute unpackaged executable code, and tests that access unpackaged
online resources that are not executable code? For example, under this
interpretation, it would be unacceptable for a Python package to download
test libraries from PyPI via pip during autopkgtest, but it would be
acceptable for youtube-dl to have an autopkgtest that asserts that it
is still able to download a video from Youtube (which is its purpose).

Or are the ftp team deliberately contradicting that design point and
saying that, while the autopkgtest framework was designed to support
tests that access the internet, such tests are acceptable for Debian
main? (If so, this would be similar to the way dpkg is designed to
support debian/patches/ubuntu.series, but Policy says such packages are
not allowed in the Debian archive.)

    smcv

Reply via email to