autopkgtest <src/pkg/directory> "built tree" detection is surprising and not well documented

[Simon Chopin]

While working on needrestart autopkgtests, I've run into issues testing it using my standard invocation:

autopkgtest . -U -- lxd autopkgtest/ubuntu/noble/amd64

The runner wouldn't install the built package but would just keep whichever version is in the archive, while still using the new sources for getting the test scripts, which of course would result in failures :)

It works fine with packages not part of the base image, e.g. hello.

[Skia (hyask)]

Thanks for the report.

What version of autopkgtest are you using? I expect 5.32ubuntu3 from Noble?
Is the same issue also happening using upstream's master branch?
```
git clone https://salsa.debian.org/ci-team/autopkgtest/
./autopkgtest/runner/autopkgtest . -U -- lxd autopkgtest/ubuntu/noble/amd64
```

[Simon Chopin (schopin)]

Confirmed on salsa, and yes I'm using noble, 5.32ubuntu3, sorry about that.

One solution I could think of is to go through the list of dependencies and add a strict version if it's a binary generated by the tested source package (lib/adt_testbed.py, install_apt)

[Paul Gevers (paul-climbing)]

I'm not sure if it's going to help us much, but can you run with `-ddd` and attached the (compressed) log to this log for inspection?

[Paride Legovini (paride)]

Hi, autopkgtest should already setup pinning to ensure that the tested package is the built one.

Before digging any deeper let's check one thing. When you specify a source package directory, autopkgtest distinguishes between a "built tree" and an "unbuilt tree". In the case of a "built tree", all test dependencies get satisfied by archive packages (see the manpage, under TESTING A DEBIAN PACKAGE).

So, if "." is a "built tree", the behavior you observe is expected. Now, what is it that makes autopkgtest consider a tree a "built tree"? It's the presence of the debian/files file.

@Simon can you please check if this is it? Thanks!

[Simon Chopin (schopin)]

I'll be damned. That's the issue, indeed. I tried to reproduce with a fresh `hello` but couldn't so I wrongly concluded that it was because it wasn't on the image.

I'd argue it's still a bug, as in *this should be documented*! I'd never consider that an unpackage source package would be in a 'built' state after dpkg-buildpackage -S :)

[Simon Chopin (schopin)]

After a bit more reflexion, I'd even argue that this 'built tree' exception shouldn't exist in the first place as it seems like a nice footgun, but I'm guessing it's not that simple, so in the mean time I'll just go and amend my wrapper script to not use `autopkgtest .` but rather `dpkg-buildpackage -S && autopkgtest ../$package.dsc`

[Paride Legovini (paride)]

Heh, this can indeed be surprising, the only reason I knew is because I've been bitten by this in the past.

Neither me nor Paul immediately why that built-tree detection and treatment is needed; what I can see is that it was implemented a long time ago, likely for good reasons we'll need to figure out before changing the existing behavior.

[Paride Legovini (paride)]

Speaking of your workflow, instead of `dpkg-buildpackage -S` you could call the clean target before running autopkgtest, to make sure the tree is "unbuilt"

  debuild -- clean && autopkgtest ...

dpkg-buildpackage -S calls the clean target, so this should just work in your case.