Patrick Schoenfeld wrote:
> 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.
And I don't see the need for such an additional layer
>> 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.
So you have two ways now how to disable service, one via the traditional
symlinks and the other via RUN_* variables. not a good idea imho
>> 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.
Care to elaborate?
>
>> 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
^^^^^
Definitely not every, some do. And I don't like this behaviour as it doesn't buy
you anything.
Imo you failed to clearly motivate why we need such an additional layer. I am
not convinced yet about the benefits of such an approach.
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature