Hi Ian, On 22-06-18 15:25, Ian Jackson wrote: > Ian Jackson writes ("Re: Bug#901897 closed by Jonathan Nieder <firstname.lastname@example.org> (Bug#901897: fixed in git 1:2.18.0~rc2-2)"): >> I think it _is_ optional. At least, it was in adt-run. I think >> autopkgtest has much of the same logic. It's a question of putting >> together the right rune to specify what you want. > > I am wrong. autopkgtest has a completely different command line > parser to adt-run. > > https://manpages.debian.org/unstable/autopkgtest/autopkgtest.1.en.html > https://manpages.debian.org/stretch/autopkgtest/adt-run.1.en.html > > adt-run's command line is a bit abstruse but I think it is more > powerful. Unfortunately adt-run was deleted. Which option did you have in mind? I don't spot anything that isn't in autopkgtest either, but I didn't read carefully. Remember what the situation is. We start with testing and we only add a limited set of apt-pins. In the case we are discussing, the package we want to test is NOT in the pin. Then we ask autopkgtest to determine which test suite to pick. Naturally, it will pick the version from testing. Then we install the test dependencies. Due to not all dependencies from the packages from unstable being fulfilled in testing apt-get install fails and in the *fallback* we install the new version of the tested package, which is now out-of-sync with its own test suite. Is there an option in adt-run that would either (a) pick the right version to start with or (b) will go back and try to install the test dependencies for its unstable test suite? It is this option (b) that I am thinking about to implement as I don't believe autopkgtest should be able to do (a). Paul NB: juliank is currently implementing a new native apt solver that should be able to solve the issues that we have for which we wanted the aspcud solver. If that lands, I think I will not spend my time on fixing britney right now, but instead just implement this (b) option.
Description: OpenPGP digital signature