(In reply to Ludwig Nussel from comment #25) > The suggested fix again enables apparmor even if it was intentionally > disabled before. That could break services and potentially even lock out > people. There is no easy way out here anymore. So I'd say the released > update should be reverted ASAP. A follow-up update should be released that > removes that service file but still contains the other fixes. I'd agree with that two days after the broken update went out - but reverting something 6 weeks later is calling for more trouble IMHO. I just did some testing, always restarting from a clean 42.2 JeOS without any AppArmor package. In the following tests, - "oss" means the original 42.2 oss repo - "update" means the current 42.2 update repo - "my test repo/packages" means home:cboltz:branches:OBS_Maintained:apparmor 1) - install AppArmor from oss (-> enabled) - update to the latest update (-> disabled) - update to my test package (-> enabled again - so my fix is working) 2) - install AppArmor from update repo (-> enabled) - update to my test package (-> enabled) 3) - install AppArmor from oss (-> enabled) - "insserv -r boot.apparmor" (-> disabled) (note: systemctl disable doesn't work for the initscript) - update to my test package (-> disabled) 4) - install AppArmor directly from my test repo (-> enabled) I'd argue that all this looks good and covers the usual upgrade paths. Yes, there's another possible case: - install AppArmor from oss (-> enabled) - updated to the last update (-> disabled) - manually re-enable AppArmor with systemctl enable apparmor (-> enabled) - disable AppArmor some days later with systemctl disable apparmor (-> disabled, but symlinks in /etc/init.d/boot.d/ will still exist) In this case AppArmor will be re-enabled with my test update - but I'd say this way is the most unlikely case to happen ;-) Did I miss another possible upgrade/enable/disable path? Note: thanks to bug 1029696 we shouldn't wait too long with pushing out an update. I'll submit the update tomorrow if nobody objects.