Dear all, We are nearly there to enable migration being gated by autopkgtest results. Unfortunately I recently realized (after implementation and deployment of what I thought would be the solution) that the current situation is possibly not good enough yet. I'd like to solicit for your help on determining the way forward. This e-mail is basically a follow-up of my earlier e-mail [1] about needed improvements. Before I start with my real issue, let me note that needs-recommends is now deprecated (it is still supported, but the docs and lintian warn against it). So I don't bother about it anymore, except somebody (me) still has to fix autodep8 to not emit it. Let me describe the problem and the current status. The migration software (britney2) is now taking versioned dependencies, breaks and conflicts of the binary packages from the source package that wants to migrate into account when requesting the tests. It will add versioned dependencies that are not in testing and it will add packages from unstable when their version in testing is broken by (or conflicts with) anything needed from unstable (recursively). However, it is not having enough information to do this well (at least, I fear), because of the following: 1) it only knows the Testsuite-Triggers, but it is missing possible version information of test dependencies. (Possibly fixable by dpkg-source, but that will take time to propagate and then the Testsuite-Trigger field changes syntax and meaning). 2) @builddeps@ is not resolved by dpkg-source, so the migration software doesn't know if build-depends should be evaluated for the list (currently the migration software doesn't add them). (Possibly "fixable" by always evaluating them, or possibly fixable by enhancing dpkg-source). 3) test dependencies generated by autodep8 are fully unknown to the migration software. It seems (but I haven't verified properly) that e.g. with r packages the test dependencies can be versioned as well. I was hoping that with the migration software now calculating the sets from unstable, we would be able to disable the apt-get fall back in autopkgtest (I even uploaded debci yesterday to the unstable archive which now disables the fall back), but because of the above I am not sure how well that is going to behave. I still want to try it out, as I can repair it manually for the time being, but I am convinced that turning the apt-get fall back off now isn't sustainable without additional solutions. Remember that that fall back had its own issues: after the fall back all packages that are installed will be upgraded to the version in unstable, even when this isn't needed; in some situations this leads to apparent regressions, while the package under investigation is just broken in unstable, but not in testing (bug 896023, LP 1760810, and at least one case I can't find back) So, either we need to solve the issues above, or enable the apt-get fallback again and live with it or we need to turn to other solutions. I already discussed a bit with nthykier on e.g. running autodep8 during the dpkg-source phase to add that information to the dsc file, but we are both not fond of the idea that even more magic goes in there. People could (but also shouldn't because the info is already available elsewhere in the source) update the d/control file with the right information. Comments? Ideas? I am looking forward to them. Paul [1] https://lists.debian.org/debian-ci/2018/06/msg00025.html
Attachment:
signature.asc
Description: OpenPGP digital signature