Re: LSB specification (or not) of /etc/init.d

Mats-

> 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 experience with the POSIX and UNIX base OS WGs is that option (3) would
garner you the most consensus and create the least "invention" - both of 
which
are Good Things at this stage. 


-------------------
Mark Brown/Austin/IBM 
STSM, UNIX/Linux OS Standards
IBM Systems Group, Linux Technology Center
[email protected] (512) 838-3926 [TL 678-3926)

[email protected] wrote on 05/06/2005 11:33:50 
AM:

> 
> We don't seem to be able to come to consensus on the /etc/init.d
> issue.  The LSB 2.1 spec (and presumably earlier versions) did say
> that initscripts are installed to /etc/init.d:
> 
>  19366  8.4. Installation and Removal of init.d Files
>  19367
>  19368     An init.d file is installed in /etc/init.d (which may be a
>  19369     symlink to another location). This can be done by the package
>  19370     installer. See Script Names>. During the package's
> postinstall
>  19371     script, the program "/usr/lib/lsb/install_initd" configures
>  19372     the distribution's boot script system to call the package's
>  19373     init.d file at the appropriate time.
> 
> There's one viewpoint that the above is the right way to do things
> (ignoring many of the imprecisions in the wording, I'm talking about the
> intent conveyed): "everybody" has an /etc/init.d; and allowing installs
> directly to this system location, the system's native package manager
> can
> get involved in management of this file, particularly doing "something
> appropriate" if the initscript is marked as a configuration file.
> 
> There's another viewpoint that says the LSB should not get this
> specific about system locations; not all implementations indeed will
> have /etc/init.d and should not be forced to (we've heard about schemes
> with a fast-boot objective that may do something quite different),
> and that it's better to abstract the precise details away - packages
> should install their initscript to a package-private location (probably
> /etc/opt/{package} or /etc/opt/{provider} as carved out by FHS) and then
> ask the system to do the right thing to make it work.  This seems to
> have been the original intent for install_initd, but it ended up being
> worded to require the script already be in /etc/init.d.
> 
> In writing up lsbinstall, we attempted to restore the abstraction, and
> in thinking about it, it seemed conceptually there were two distinct
> steps: registration and activation. The former is getting a script into
> a system-specific location, database, whatever; the latter is making
> it actually activate appropriately on runlevel changes. The activation
> details may change - the sysadmin may choose, for example, to no longer
> start a daemon that used to be enabled, but leave the package installed.
> So an installing package would likely do both steps, but leaving a
> way for this to change later seemed appropriate.
> 
> So in LSB 3 draft wording we describe a model where a package, after
> installing, first calls lsbinstall for the "registration" step, then
> calls install_initd for the "activation" step. 
> 
> However, the need for two steps seems to have proven unpopular; it's
> also possible to describe only one step which combines
> register+activate,
> and leave it unspecified (i.e., leave to system-provided tools) how the
> activation state is later manipulated.
> 
> So it seems there are several possible courses of action (and
> before anyone brings it up: yes, we're squarely into "invention"
> space here, but this init-script abstration was already an
> existing invention, we're still trying to get it right, and we're
> working on an implementation for the lsbsi to make sure it's
> actually reasonable to write one to what the spec says):
> 
> 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.
> 
> 
> _______________________________________________
> lsb-discuss mailing list
> [email protected]
> http://mail.freestandards.org/mailman/listinfo/lsb-discuss