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

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.=20

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=20
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.