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 pinning. 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? Paul ¹ 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