Stefano Zacchiroli schrieb am Freitag, den 04. März 2011: > On Wed, Mar 02, 2011 at 11:54:05AM -0800, Steve Langasek wrote: > > At present there *is* no reliable sysadmin interface for enabling/disabling > > services. update-rc.d is not it; many admins have been using 'update-rc.d > > -f remove' for years, but this is /wrong/ and it is /documented/ that this > > will cause the links to be readded on package upgrade. policy-rc.d is not > > it; the spec for this is bloated and I've never heard of an admin who's ever > > bothered implementing anything more than a "don't start any services in a > > chroot" policy using this. And /etc/default/* isn't it; no consistent > > variable naming, not implemented for all services (and shouldn't be), so > > it's not scriptable, so it requires vi. > > > > So the mv command above *is* the current method. And we're in desperate > > need of a better one. > > Right, this is the technical problem to solve: find one (handy) method > to enable/disable services and "bless" it as the recommended one. > > There seems to be a bug report against sysvinit-utils (that package > which ships /usr/sbin/service) about this already: #545325. I'm cc-ing > the bug log with this mail. For the bug log reference, this discussion > started on -devel at > <http://lists.debian.org/debian-devel/2011/03/msg00035.html>. > > Assuming a kind soul devises a patch for #545325, which shouldn't be > *that* hard, would that be enough to fix the general problem or would we > need something else in addition? (beside documentation, of course) > > In particular, considering the possibility of other init systems coming > (see #591791), would /usr/sbin/service enable/disable still be a proper, > init-system-independent, abstraction? I don't see a problem in shipping my own server implementation with file-rc is neccessary. Alex
Attachment:
signature.asc
Description: Digital signature