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

autopkgtest gating migration, nearly there. But ...

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

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

Comments? Ideas? I am looking forward to them.


[1] https://lists.debian.org/debian-ci/2018/06/msg00025.html

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: