[lsb-discuss] Re: [Lsb-wg] LSB specification (or not) of /etc/init.d

[Nick Stoughton]

On Fri, 2005-05-06 at 09:33, Wichmann, Mats D wrote:
> 1. Make the /etc/init.d requirement more explicit (i.e., document
> elsewhere in the LSB that this is a required directory-or-symlink),
> and make the lsbinstall init-script install functions look just like
> install_initd, which would mean install_initd can be deprecated
> (or, equivalently, that there's no need for lsbinstall to worry
> about this fuction).  Effectively this is "do nothing" except for 
> promoting /etc/init.d a little more clearly.
> 
> 2. Drop the /etc/init.d requirement and use lsbinstall to provide
> the "registration" abstraction: lsbinstall causes the initscript
> to go into the appropriate unspecified system location, and returns a
> token (expected to be the name of the script) which can then be fed
> to install_initd for activation.
> 
> 3. Use lsbinstall to provide both functions with a single invocation,
> and don't try to describe "registration" and "activation" as separate
> concepts; leave unspecified what step causes activation.  In this case,
> install_initd can be deprecated but we would continue to allow the LSB
> 2.x behavior in LSB 3.
My personal preference is choice 2 ... 

While there may be a clear consensus amongst the current mainstream
distros to use /etc/init.d (as required by earlier versions of the LSB),
I know of several alternative approaches. I also believe strongly that
this is a two stage operation ... registration and activation should not
be rolled into one.

Option three contains as much invention as option 2, and adds to the
overall churn in invented interfaces in the LSB ... install_initd was an
invention in the first place, I don't think we need to deprecate it yet!
It also gives the system administrator less control over the final
layout.

Option one would be my second choice ... this is the least change from
the past, and is supported by everyone we care about in the short term!
I just don't think we should be dictating implementation here.
-- 
Nick Stoughton      USENIX/FSG Standards Liaison
nick at usenix.org     (510) 388 1413