Hi all, Thanks Ian for chairing the BoF, I think it was useful to have it. On 02-08-18 11:30, Martin Pitt wrote: > Simon McVittie [2018-08-02 9:59 +0100]: >> On Thu, 02 Aug 2018 at 06:49:33 +0100, Ian Jackson wrote: >>> ## unsatisfiable test-dependencies should not be a test failure >>> DON'T use apt in your script >>> Use flaky restriction + it needs a fix in autopkgtest to properly support that >>> (as mentioned by Ralf Treinen, it doesn't work yet). >> >> Sorry, I don't follow. Do you mean "don't use apt in your script, ever" > > I would also recommend to use apt-get, not literally "apt". The latter is nice > for interactive command line usage, but too fancy/graphical for logged script > output, and its CLI is not stable. > > But I suppose you really meant "apt-get" as well here. Why should that be > flaky? Because of unstable mirrors or something? Yes, I meant apt-get as well. The problem is that I think often it is to work around issues. My take home message of the BoF was that people are encountering issues we aren't aware of. Using apt is often an example of that. Take gnugp2. I think it does it to add multi-arch. But the test fails in our migration setup because it doesn't "fix" the pinning that we have in place to get the right packages installed. As a global reference I think we should say: package install goes via autopkgtest except when it is really apt(-get) or something close to it you want to test. But also, think about network hickups, retries etc. Therefor, often these things turn out to be flaky. (True, with skippable that can be fixed, but as a general recommendation I want to say, don't call apt-get yourself, but file a bug about the use case you want supported. >> (Some useful test cases can't really avoid using apt, in particular the >> ones for debootstrap and nss-mdns.) Sure, exceptions. > Yeah, that. I also encountered or even wrote tests where it was inevitable to > do some pre-setup or a particular order or something else which you can't > express through a declarative Depends:. Or you want to test an apt related > package :) But be prepared for breakage. Basically you would need to "copy" some of the code autopkgtest has to make this "robust". There is currently my MR 29 [1], that is about optionally disabling the apt fallback in autopkgtest, which I want to start using on ci.d.n once britney can calculate sets of packages that need to come from unstable. I consider this fallback a gross hack (I think pitti once acknowledged to me he considers it a (maybe not gross) hack too). But is shows our setup is "weird" and calling apt(-get) in that situation is somewhat fragile. Paul [1] https://salsa.debian.org/ci-team/autopkgtest/merge_requests/29
Attachment:
signature.asc
Description: OpenPGP digital signature