@Steve, you said 'and started apparmor', is that because you are stating a preference for this to not be a task or because 'and started apparmor' is also ok with a task?
You stated that rc-sysinit shouldn't directly depend on apparmor if it can be started and stopped if a task over the life of the system. I expected we would 'start' the apparmor task in package upgrades of apparmor, click-apparmor and apparmor-easyprof-ubuntu, however, we can instead just move the script portion of this job out to the new /lib/apparmor/load-policy (or something) and then have the apparmor upstart job use it while having the apparmor, click-apparmor and apparmor-easyprof postinsts call this script directly rather than restarting the upstart job. Is there a better way to handle this that is perhaps more "upstarty" (noting that we are transitioning to systemd soon)?
@Steve, you said 'and started apparmor', is that because you are stating a preference for this to not be a task or because 'and started apparmor' is also ok with a task?
You stated that rc-sysinit shouldn't directly depend on apparmor if it can be started and stopped if a task over the life of the system. I expected we would 'start' the apparmor task in package upgrades of apparmor, click-apparmor and apparmor- easyprof- ubuntu, however, we can instead just move the script portion of this job out to the new /lib/apparmor/ load-policy (or something) and then have the apparmor upstart job use it while having the apparmor, click-apparmor and apparmor-easyprof postinsts call this script directly rather than restarting the upstart job. Is there a better way to handle this that is perhaps more "upstarty" (noting that we are transitioning to systemd soon)?
Thanks!