On Sun, 26 Feb 2023 at 19:09:59 +0100, Daniel Leidert wrote:
Am Sonntag, dem 26.02.2023 um 19:45 +0200 schrieb Adrian Bunk:
[..]
Debian Policy §4.9 says that *attempting* to access the internet
is forbidden:
For packages in the main archive, required targets must not attempt
network access, except, via the loopback interface, to services on the
build host that have been started by the build.
And the "test" target is not listed as a required target there.
If the series of events is:
* dpkg-buildpackage invokes build-arch or binary-arch or their -indep
equivalents, which are required targets;
* some dependency of those required targets invokes the test target;
* the test target tries to access the internet
then I'm sorry but as Adrian said, that's a required target attempting
network access. The network access isn't directly written into the recipe
for the required target, but it's indirectly caused by the required
target, so this is in-scope for the Policy rule quoted here.
If that wasn't the intended interpretation, then this Policy rule would
be fairly pointless: if Policy §4.9 doesn't allow doing something like
build-arch:
make
make test with_internet=yes # not allowed
then it also shouldn't allow this:
build-arch: try-to-bypass-policy-4.9
@echo "this is not the Internet access you are looking for"
try-to-bypass-policy-4.9:
make
make test with_internet=yes # also not allowed!
which it seems like your interpretation would allow?
If the test is gracefully skipped in the absence of internet access, then
I'm not sure I would necessarily agree with Adrian that it's a *RC* bug
(not every Policy violation is RC, only serious Policy violations), but
I think it's certainly a bug.
As Adrian said on the bug, a good way to handle packages whose test
suites require internet access is to disable the test suite (or just
the part of it requiring internet access, if you can) at build time
(instead of probing for ability to talk to the internet, always take the "cannot talk to the internet" code path), and use an autopkgtest with
the needs-internet restriction to get that coverage back.
Having an environment variable like TESTS_NO_NETWORK that makes the test
suite take the "no internet" code path, and exporting that variable
in debian/rules, is one fairly straightforward way to achieve that. For example, game-data-packager's tests/download_shareware.py skips itself
if DEB_BUILD_TIME_TESTS is set, and debian/rules exports that variable.
I personally think it would also be OK if the Ruby team defined a
way that maintainers could opt-in to running build-time tests that do
access the internet, if you find that useful, as long as it's not the
default code path; for example you could set it up so that that adding x-ruby-tests-can-use-internet to DEB_BUILD_OPTIONS would have that
effect. (This is only my opinion and has not been through the Policy
process, and I don't know whether project consensus would agree with me,
but I hope it would.)
smcv
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)