Hello Chris, On Tue, Nov 08, 2016 at 06:56:10PM +0000, Chris Lamb wrote: > Hi Andreas, > > > Simply *why* is this error added? > > I added this Lintian check after #838966 was filed against one of my > packages. [...]
Thanks for providing this background info. Though I have to say this only makes me more certain we're heading down the wrong path here. Consider the case when someone has bind-mounted enough bits into their chroot that invoke-rc.d starts systemctl instead of directly invoking the init script. What about upstart (which is still supported in invoke-rc.d even though I hear upstart is no more)? And open-rc? And ... ? I'm hope we agree that because your package ships an init script (|| \ systemd unit || ...) you should not start depending on lsb-base && systemd && ... (in other words every init system?! Will it even work to run systemctl in the chroot talking to systemd outside the chroot starting things inside the chroot? I'd guess no.) I'm still hoping we can solve this in one generic place. Without having thought it through I feel like pointing the finger towards init-system-helpers (invoke-rc.d and update-rc.d). I would think that when you run an init-less (aka *buildd*) chroot you would also have a policy-rc.d rule that disallows running of init-scripts etc. via invoke-rc.d (and update-rc.d). Maybe we could even automate that by having the *-rc.d tools auto-detect we don't have an init system in the chroot and treat that as if a policy-rc.d rule was in place. (Someone with experience on how buildd setups and policy-rc.d actually works would be welcome to hear from here.) I'm sure there are a bunch of trivial init scripts that will work to start in a init-less chroot, but I would think it can't be a generally supportable concept. Likely if you skip the init system you should start whatever you want to run directly. Ideas and/or comments welcome. Regards, Andreas Henriksson PS. sorry for both being pessimistic and incapable of writing short mails.