Hi, I faced the same Lintian warning when preparing the apparmor 3.0.3-1 upload: debhelper moves the systemd unit to /usr/lib/systemd/system/apparmor.service
I was wondering whether Lintian was correct and whether this would actually cause trouble, especially on non-merged-/usr systems, so I installed the resulting packages in an up-to-date sid VM with non-merged-/usr. At first glance, everything seems to work just fine: - The service starts at boot as expected. - The output of "systemctl show -p UnitPath --value" and "systemd-analyze unit-paths" does include /usr/lib/systemd/system. So my impression at this point is that debhelper is doing the right thing, while Lintian is incorrect when assuming that /usr/lib/systemd/system is ignored. I'm wondering if I've missed anything. Theodore, you mentioned on -devel@ that this would "[break] on systems that don't have usrmerge installed". Could you please explain what it breaks? I'll refrain from uploading apparmor 3.0.3-1 until this is clarified. I've spotted one (somewhat cosmetic) problem though: the symlinks set up for Wants=/WantedBy= still point to /lib so they are now broken: /etc/systemd/system/sysinit.target.wants/apparmor.service -> /lib/systemd/system/apparmor.service This would of course not matter at all on a merged-/usr system. Even on a non-merged-/usr system I could not spot any problem this would cause, apart of some potential administrator confusion. Should I report this separately? Hoping it helps, cheers!
