On Mon, Nov 17, 2014 at 02:38:04PM -0200, Henrique de Moraes Holschuh wrote: > On Mon, 17 Nov 2014, Anthony Towns wrote: > > If deb-systemd-* were to get merged in, it might be worth doing a name > > change at the same time, I guess. Changing either before jessie doesn't > > seem remotely plausible. > > > > I wonder if it would make sense to just merge it all into the "service" > > command; ie: > > > > # service --use-policy ssh start > > # service --use-policy ssh restart > > # service ssh enable > > # service acpid.socket mask-for-upgrade > > "service" is an user interface, while deb-systemd-*, invoke-rc.d, and > update-rc.d are first and foremost to be used by a package's maintainer > scripts (postinst, etc). They have different design goals.
My understanding is that update-rc.d is the recommended way for admins to enable/disable services. Is that incorrect? (It's what I've documented in my proposed init guide/policy) Obvious alternative idea, provide a maintainer script oriented tool under a different name: service-maintscript ssh start service-maintscript ssh enable service-maintscript acpid.socket mask-for-upgrade But if we did that how would we recommend admins enable/disable services? Just use the native stuff (rm /etc/rc?.d/S*ssh; systemctl disable ssh)? > IMHO it is best that we keep system interfaces separate from user interfaces > like "service", Yeah, I see where you're coming from. My intuition goes the other way; that it's better to have a single tool for both uses if that's feasible. We don't have anything special for doing cron jobs via packages compared to what admins might do to add a cron job, eg. Maybe that's a bad intuition though. BTW, it occured to me that it seems like a wart that update-rc.d doesn't respect policy-rc.d -- as it stands, policy-rc.d can prevent a service from (re)starting during install/upgrade, but it'll still start on the next boot. Is that just something that never got thought of / done, or does it actually make sense? Cheers aj -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117170715.ga13...@master.debian.org
