[apparmor] [PATCH] Add support for variable expansion in profile names, and attachments

[John Johansen]

On 06/09/2015 04:45 AM, Steve Beattie wrote:
> On Mon, Jun 08, 2015 at 08:46:09PM -0700, John Johansen wrote:
>> On 06/08/2015 08:03 PM, Steve Beattie wrote:
>>> I haven't waded entirely into this patch yet, but I just wanted to make
>>> a comment about something:
>>>
>>> On Mon, Jun 08, 2015 at 04:29:03PM -0700, John Johansen wrote:
>>>> On 06/08/2015 02:23 PM, Christian Boltz wrote:
>>>>>> --- /dev/null
>>>>>> +++ b/parser/tst/simple_tests/vars/vars_profile_name_12.sd
>>>>>> @@ -0,0 +1,9 @@
>>>>>> +#=DESCRIPTION profiles declared with the profile keyword can begin
>>>>>> with var +#=EXRESULT PASS
>>>>>> +
>>>>>> +@{FOO}=bar baz
>>>>>> +@{BAR}=baz foo
>>>>>> +
>>>>>> +profile /does/not/exist@{BAR} @{FOO} {
>>>>>> +  /does/not/exist r,
>>>>>> +}
>>>>>
>>>>> As discussed on IRC: The attachment will expand to {bar,baz} - and 
>>>>> that's not a valid attachment (not starting with /), so this test should 
>>>>> fail.
>>>>>
>>>> Nope, as discussed this needs to be fixed in a different patch.  And the
>>>> simple_tests don't have a way to encode an xfail so that the tests won't
>>>> fail while that patch is being worked on
>>>>
>>>> Basically we go with PASS for now, and when the fix is done it will cause
>>>> this test to FAIL, and need to be patched at that point.
>>>>
>>>> The only other options are fixing the tests to accept an xfail, sorry I
>>>> am not doing that atm, changing it to disabled, or dropping the test
>>>> which I would rather not do.
>>>>
>>>> dropping the test means it will get lost, setting it to disabled means
>>>> it will get lost as well as it will be forgotten then the patch finally
>>>> lands, and not get updated.
>>>
>>> Actually, some jerk already implemented xfail for you, in the form of
>>> marking a test with the additional header comment:
>>>
>>>   #=TODO
>>>
>>> To be fair, as far as forgetting goes, we do have two existing tests
>>> that are marked TODO; the issues they cover apparently have been
>>> addressed as they currently succeed.
>>>
>> err shouldn't an xfail result in the test set failing if it actually fails?
>> that way we can fix the test to be fail instead of xfail
> 
> That's not the way perl's todo mechanism works by default. Though it's
> likely possible to do some trickiness with Test::Harness to figure out
> if any todo tests are passing and register the run as "failing".
> 
then why would I want to use it, over using the "wrong" EXRESULT + a comment
about what the test should do?

using the "wrong" EXRESULT ensures that the test will pop up when the code
that fixes the xfail, xpass is added. This ensure that the test will get
updated, otherwise, people forget and the tests don't get updated.