[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

autopkgtest: versioned triggers and fixing "Test dependencies are unsatisfiable with using apt pinning"

tl;dr; I want to fix the "Test dependencies are unsatisfiable with using
apt pinning. Retrying with using all packages from unstable" situation
because it has unwanted side effects¹. But how to do it?

Hi Martin, Julian, all,

After a discussion between pitti and me on IRC about using an
alternative resolver for apt I have been thinking (and playing a bit²)
about how to prevent the "Test dependencies are unsatisfiable with using
apt pinning. Retrying with using all packages from unstable" situation.
Regardless of the alternative resolver, I think we need to enhance
autopkgtest to accept (trivial) and use (this e-mail) the required
version of the trigger.³

If we use the alternative resolver (assuming I can fix a broken pipe and
it actually works as I expect it to), I believe we need to prevent it
from coming up with a solution where all packages are installed from
testing. Because if there is at least one solution to the request, but
no solution at all taking the required packages from unstable, the
alternative resolver will return that. I don't think there is a way
around that, as we have to relax (APT::Solver::Strict-Pinning=false) the

If we want to fix this issue and we don't go for the alternative
resolver, we have to rewrite how we install the packages in the testbed.
Currently we create an dummy package that is installed with dpkg and we
ask apt to fix the broken package. But reading the man page of apt, if
we request it to install a package with the version that we want, it
takes the right dependencies from unstable. So if we want to use that,
we have to ask apt to install the required packages ourselves with the
version specified (or with /unstable).

And yes, for both paths this means figuring out which packages are
needed at all (maybe apt --simulate) and translating src:package to
binary packages in more than the current place.

What do you think?


¹ The problem is that suddenly all required packages can (and if the
version is higher will) come from unstable. This can cause the following
two issue:
1) A regression in a low level package can show up in multiple packages
that want to migrate. A recent example of that is numpy (via
python(|3)-numpy) or python-ase in unstable that broke (all current
version of) gpaw (and for that has an RC bug) but (the latest version
of) gpaw with the python-ase from testing is OK.
2) If the package of which the autopkgtest is run has a newer version in
unstable, that version will be installed, while the old version of the
test is run (bug 896023, which we need to fix even when we fix this
pinning stuff, because it will and should not be fully prevented)

² I think I implemented the alternative resolver in adt_testbed.py
locally. I couldn't yet get the SchrootRunner tests to run because in
the test (or worse, also in reality, I don't know which yet) the
apt-to-aspcud pipe breaks in the autopkgtest framework and I haven't
been able to debug it yet (@jak: any ideas?).

³ Going this route also prevents unwanted PASS in the case where we are
too quick with testing and the new version breaks (albeit we can/should
probably work around that by enabling the incoming archive in debci).
Maybe (I haven't checked) it may even fix bug 896698, where autopkgtest
--needs-recommends is silently failing to install the recommends (@jak:
do you know apt's behavior here?).

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: