Christian Boltz wrote:
[...] I'm seriously thinking about adding something like grep ' apparmor.service' /usr/lib/systemd/system-preset/*.preset >/dev/null || systemctl enable apparmor.service to make sure we get the expected result if the preset package wasn't updated yet, while honoring the preset if it is there. This doesn't cover all cases (especially tumbleweed -> newer tumbleweed [1]), but at least updates from <= 13.2.
If apparmor was previously installed but not enabled you cannot know whether the admin intentionally left it in that state. Maybe the admin tried to use apparmor, ran into problems and didn't enable it at boot. Therefore we cannot suddenly enable apparmor on upgrade just because we changed our minds and enable apparmor on new installs again now. If that is your scenario please do not add workarounds. The behavior is expected as is. The current presets method indeed has blind spots but I'm not sure you hit one in your case. Anyways, there was a discussion about that a few months ago: http://lists.opensuse.org/opensuse-packaging/2014-11/msg00061.html We also discussed some smarter presets handling offline but I'm not sure if Stanislav already had time to draft something. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org