Hi, On Wed, Apr 01, 2009 at 06:12:29PM +0200, Michael Biebl wrote: > I don't like this idea of RUN=yes variables in /etc/default. > > 1.) There is already a documented interface, how to disable a service (i.e. > renaming the S?? symlinks for that runlevel to K??). Adding another layer to > do > this is just confusing and inconsistent. > There are tools like sysv-rc-conf which can handle that for you. Enabling a > service is then as easy as sysv-rc-conf $service on|off
yes, that is true. This concept is however limited in so far that you cannot decide before installing a certain service, weither it starts after installation. Which is important if you want to avoid running wrong/half configured services in your network. Basically the approach is just to give some more possible choices to the users. > 2.) It makes the init script useless. That is definitely not true. The init script still stays a common known interface to control a given service. The idea just adds another layer of control. > I often install services, which I only need from time to time, so I disable > them > via the approach above and can start them on-demand vi /etc/init.d/service. > A RUN=no will break that. Hu? How should that break it? You do not need to set RUN_<SERVICE>=no, if you don't want to. You can still disable the service on boot, by disabling them via sysv-rc-conf and interface with them via invoke-rc.d. > Imho the only sane option is, to get rid of those RUN_ variables as much as > possible and advertise tools like sysv-rc-conf more (or even install them by > default). No, because this approach basically does not help anybody. > There are indeed services though, which should *not* be started by default, as > e.g. they need to be configured first. But instead of inventing such a RUN_ > variable, the init script could directly check if its prerequisites are given > and only start in that case. It then can also output a more sane error > message, > telling the user what it is missing and how he can change that. Well, its no invention, becuase the RUN_ variables already exist. They are just used inconsistent and every init script re-implements the parsing of them, instead of doing it in a central place with added benefit. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
