Comment 7 for bug 1629203

Yes, I remember that Novell had the "great" idea to force a pre-alpha package management ("Zenworks") into SLE (IIRC SLE 10) and openSUSE 10.1. On the positive side, they learned that this was a terrible idea, and SUSE developed libzypp and zypper - which turned the Zenworks desaster into the best package management openSUSE and SLE ever had :-) so in the end Zenworks improved things, even if it didn't happen in the way Novell had expected.

Back to the bugreport:

First, thanks for the exact reproducer! I finally understand what you did, and can reproduce the problem (using nearly-2.11 aa-logprof).

The problem is that you start with a hand-made empty profile in step 2 that does not include tunables/global, and then use aa-logprof to extend it. (Creating a profile with aa-genprof will always include tunables/global.)

aa-logprof doesn't check if variables that are used in an abstraction are defined in the profile file - and if the file doesn't have tunables/global, there are big chances that they aren't defined. The question is how we should handle this. Options I can imagine:

a) hardcode to always include tunables/global. This will annoy people who for some reason don't want it, so I don't like this idea too much - even if profiles without tunables/global are very rare.

b) when adding an include, check if all variables are defined. This is possible, but probably some work. It would also mean that aa-logprof must know where those variables are defined, and ask the user about including this file in the global area. That would be something totally new, because right now it only asks about things inside the profile (well, aa-mergeprof already asks about global includes).

c) declare this bugreport as user error - you broke it, so you own both parts ;-)

So: yes, this is a valid bugreport, but it's a corner case and not too high on my TODO list ;-)