Dear Maintainer,

I noticed that the dependency of each test is added to the dependencies of the
following tests

For example: debian/tests/control contains:

Test-Command: /usr/lib/android-sdk/build-tools/19.1.0/aapt v
Depends: google-android-build-tools-19.1.0-installer

Test-Command: /usr/lib/android-sdk/build-tools/20.0.0/aapt v
Depends: google-android-build-tools-20.0.0-installer

Test-Command: /usr/lib/android-sdk/build-tools/21.1.2/aapt v
Depends: google-android-build-tools-21.1.2-installer

The observer behaviour is:

- for the test #1, it installs:  google-android-build-tools-19.1.0-installer
- for the test #2, it installs:  google-android-build-tools-19.1.0-installer &
google-android-build-tools-20.0.0-installer
- for the test #3, it installs:  google-android-build-tools-19.1.0-installer &
google-android-build-tools-20.0.0-installer & google-android-build-
tools-21.1.2-installer

And so on...

The packages named here are packages build by the source package that is being
tested

Is this expected? I expected to have only the declared Dependency to be
installed, but it seems they are cumulative.

Thank you.

Hi Fab,

Can you please specify which backend you're using? This is *not* what
I'm seeing in the runs on ci.d.n which uses lxc. As an example, one of
my packages has Depends mariadb-server in the first test, it doesn't get
installed in the second test [1]. Can you also share the sources (at
least debian/control) of the package that builds
google-android-build-tools-*-installer)? Are you sure -21.1.2-installer
has no Dependency itself on the lower version?

That's indeed not expected behavior.

Paul

[1]
https://ci.debian.net/data/autopkgtest/unstable/amd64/c/cacti/15817105/log.gz

Hello Paul,

Thanks for taking the time to look at this.

I forked the google-android-* packages to update them. The changes have
not been merged yet that may be why don't. My fork is here [1].

I checked again, I don't see such a dependency.

The test jobs are run from the automatic salsa-ci server. I don't know which
backend is actually used. Ci job is defined here: [4]

You can have a look at the logs of this job here [2]

tests/control can be seen here [3]

[1] https://salsa.debian.org/bastif/google-android-installers
[2] https://salsa.debian.org/bastif/google-android-installers/-/jobs/2069646/
raw
[3] https://salsa.debian.org/bastif/google-android-installers/-/blob/master/
debian/tests/control
[4] https://salsa.debian.org/bastif/google-android-installers/-/blob/master/
debian/.gitlab-ci.yml

Thanks
Fab

Hi Fab,

Ack.

That seems to be relevant info. The log says they use the null runner,
but I think it runs in LXC. More importantly however, the potentially
interesting thing here is that they run with a .changes as input to
autopkgtest, while I normally see logs against archive binaries. It's
the handling of *a package own binaries* in the Depends that seems to go
wrong in the case they are installed from local binaries, instead of the
archive (they are installed *before* the apt call to install the test
dependencies). At least that hints that this issue is not a generic
issue, but only for a particular (supported) use case.

Paul

Hi

Oops.

I don't know why I thought this, but I don't see it now, so it's
probably non-sense.

Paul

Hi,
Looking at this bug again, it's a bit hard to debug, as the links no
longer work. So, from here on I'm reasoning only.

I suspect that in 2021 salsa-ci was starting up the lxc container and
was calling autopkgtest with the null runner inside the container. The
null runner will not de-install the packages that it installs (it
doesn't have restore capabilities), so the test dependencies are
available during the next test. Is that what you meant? Or did you
really see the packages being installed again each time?

I tried to reproduce the issue, but with the following stanza, the
second test passes and doesn't try to install `unknown` again.
```
Test-Command: true
Depends: unknown

Test-Command: true
Depends: hello
```

Paul

## inside a testbed:
# dpkg-buildpackage -S
# autopkgtest ../*_source.changes -- null