Bug#896023: Bug#901897 closed by Jonathan Nieder <jrnieder@gmail.com> (Bug#901897: fixed in git 1:2.18.0~rc2-2)

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Paul Gevers writes ("Re: Bug#901897 closed by Jonathan Nieder <jrnieder@gmail.com> (Bug#901897: fixed in git 1:2.18.0~rc2-2)"):
> Which option did you have in mind? I don't spot anything that isn't in
> autopkgtest either, but I didn't read carefully.

I think you would have to take more manual control and pass an essay
command line to adt-run.  And you would have to know exactly what you
wanted, which I think really is the problem.

> 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.

I don't think this can be addressed without *someone* analysing the
dependencies of the proposed test case and figuring out which version
of which package will be installed for the test.

> 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?

You would have to go back and actually use the unstable version of the
test suite.  Effectively, starting again from scratch, I think.

AIUI what you are promposing is, when A's tests are being run for B's
migration:

 * tell autopkgtest to run the tests from A in testing, with an apt
   configuration which pins B from unstable.

 * autopkgtest runs an apt solver to install the to-be-tested
   packages, including B from unstable and other things preferentially
   from testing.

 * if you are lucky, the to-be-tested packages include A from testing.
   So you run A/testing's tests, with A/testing installed.

 * if you are unlucky, the to-be-tested packages include A from
   unstable.  Discard any test results so far, and restart:
   this time, tell autopkgtest to run the tests from B in testing

I think in principle this anomaly might occur for some .deb packages
and not others.  And I think britney can migrate individual .debs
occasionally ?  This all seems quite a lot of workaround.  It would be
better to treat britney as free software that we can modify to DTRT.

But I'm not offering to do anh of the work so I will let you get on
with your workaroud and wish you luck!

Regards,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.