Dear Ralf, On 03-08-18 05:15, Ralf Treinen wrote: > Now, some of these backends are not available on all architectures [3]. I > was told to use the "flaky" restriction in this case but this is not > the right solution since if the backend package is available and the > test fails when it is executed then I still want the red lights to go on. > > An alternative solution in my use case would be to use the "skippable" > restriction, apt-get install the backend in the test and exit 77 when > this fails, but this would mean using root access without a good reason.
Ok, so you actually don't want flaky, but you want to make your test depends arch aware, (Depends: x y [amd64]), in your test check if your dependency is installed and if not, exit 0 (or 77 with skippable). Please, don't use apt-get if you don't want to be testing apt. (I remember you wanted to have a test for a package that is only available in unstable, I still think that can only covered by something like flaky, see below). > In fact, I think skipping a test in case the test dependencies cannot be > satisfied should even be the default behaviour since checking package > dependencies is not the job of autopkgtest (we have testing migration > and qa.debian.net/dose for that) but I could live with it if you do > not agree with that ;-) Autopkgtest doesn't distinguishes between test dependencies and real dependencies. Often dependency failure is a real bug and as such should be triggered like that. Also, sometimes the test dependency has a typo, if we would skip that by default, it would take maybe forever before somebody notices. So I want failure to install a package be a FAIL. Paul
signature.asc
Description: OpenPGP digital signature
