Re: [exim-dev] dnssec

On 2012-06-03 at 18:00 +0100, Jeremy Harris wrote:
> On 2012-06-02 08:19, Phil Pennock wrote:
> > On 2012-06-01 at 22:01 +0100, Jeremy Harris wrote:
> >> I'm guessing from the message, due to 1f4a55daf :
> >
> > Yes. For now, just accept the update. We're going to have to figure
> > out flag-controllable munging, so that we can munge this away *unless*
> > the test is about DNSSEC in particular.
>
> I kinda think we need per-testcase-custom munge filters, in addition
> to (and possibly subsuming parts of) the wedge of string-translations
> done by munge() in runtest. A layer of indirection would provide for
> common cases - the present case would have all of
> 0002, 0094, 0381, 2202
> all pointing to a single script doing
> 'grep -v "Reverse DNS security status"' on stderr.
>
> Would this do?

I'm thinking that a hash used as a set, where the keys are "features",
could be used in the existing munge, and hash is emptied at the start of
each test, and reading the test driver could add some more keywords
(where we currently have "need_ipv4" or whatever, for instance) which
will toggle on the hash entry.

So the test case for DNSSEC would include "tests dnssec" as an entry
near the start, and munge would have:
unless exists $test_features{'dnssec'};
after the substitution to be suppressed.

Using /^tests\s+(\S+)\s*$/ for the test reading, we can then just take
$1, shove it in as the key into $test_features and so the work to add a
new test is "invent a string, use it as 'tests foo' in the driver
script, check for $test_features{'foo'} on the bit of the rig we want to
adjust". That's the minimum of fuss for each new change.

Make sense?
-Phil