@Felix
I think, that your proposal of caching test binary package separately from test output would be improvement. Maybe it would even be "good enough". I will take a look (no promises made) into this direction. But ideally... [2019-07-04 18:00] "Chris Lamb" <la...@debian.org> > I think the most common use-case is that I make some change — possibly > extremely minor — in, say, checks/foo.pm and I want to re-run the > testsuite to check that I've fixed whatever false-positive or edge-case > in a tag that I am in the process of implementing. We should optimise > for kind of pattern. What do you think? Ideally, I want test suite automatically detect: * new test directory created, test.deb needs to be built * test directory edited, test.deb needs to be rebuilt * this configuration was already checked, nothing to do + I do not want re-run perl-critic and perltidy checks aganist files, that were not changed + ... In short, I want test suite to be dependable build system from source files and test files into tarball of test logs. (~950 files or so) Right now it feels like build system written in Make -- undercontrained in one cases (you can easily get stalled results), overconstrained in another cases (you build more then necessary -- perlcritic tests, for example). To get feeling what is perfect (in sense of dependencies correctness) build system, take a look at `tup'[1]. Read the tutorial, it is worthy reading. Unfortunately for our case, `tup' only supports static dependencies and outputs (applicative), so you can't do following with it: * foo.txt contains list of files * foo.tar contains files, listed in foo.txt * foo.tar perfectly depends on foo.txt and files, listed in it. That is why I talk about Shake -- it is more complicated, compared to tup, but it supports dynamic (monadic) rules, so previous example with `foo.tar' is basic example of Shake. In theory, it is possible to implement all features I mentioned with ad-hoc Perl code, but I wouldn't volonteer to do so. @Felix: As to question of maturity, Shake is Haskell library, implemented and maintainer by well-known and well-esteemed developer. I do not expect it disappear anytime soon. Of course, I do not plan (or propose) to re-implement `dpkg-buildpackage', I just want it to be called when and only when it is necessary. [1] http://gittup.org/tup -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.