Re: LSB rc script installer requirements #1

[djb@redhat.com]

> Possible:
> 
>  1. abstract names for each stage of the start sequence
>  2. no more numbers ... list of symbols that order the start sequence

Numbers are a bit silly, yes.  The real problem, as I see it, is that
some things depend on other things to be running first.  There's no
clear way to "group" things, though.  I suppose you could group with
some scheme like:

	. system device setup (kerneld, apmd, pcmcia, etc)
	. low level service setup (networking, loggers, etc)
	. system daemons (cron, sendmail, etc)
	. user daemons (xfstt, etc)

(Not sure you need to separate the last two, however.)

The problem becomes one that within those groups some things need
to start before others (or can).  So, do you divide the groups
farther?  Not really...you end up with a single item in one group.
(Take, for example, a scenario where syslog were configured to
log to the network instead of locally...it's going to need networking
setup before logging, probably.)

To relieve that, I'd propose we have the ability to have dependencies
within the groups.  Yes, it's starting to sound very complex, but
I think for the most part the only people who will care about
dependencies are going to be the distribution builders, not the
ISVs.  Sure, we can document it for all to use, but my bet is all
they need to know is which of the above groups to stuff their daemon
into and they probably don't care about other items in that group (sure,
there will be exceptions...perhaps firewall companies or whatever might
care about dependencies, but Oracle probably wouldn't).

Now, why bother with groups at all and not just use dependencies?  It's
my experience that this would probably cause more confusion and problems
than it's worth.  An ISV (or me, for that matter) would have to decide
exactly which daemons the app required to be running first, then list
those as pre-reqs, then risk those already depending on one another or
causing circular problems by not understanding what really does need to
start first.  Perhaps others have thoughts on ways that dependencies only
might work.

I hope I'm not jumping way out on a limb too early.  But it seems to me
that we have to talk about *how* the ordering is going to happen fairly
early in this process.

>  3. must be extensible
>  4. no shell scripts
>  5. user-definable runlevels
>  6. more than 6 runlevels

What's the point of having more than 6?  Do you just mean something
like "typical systems will have 6, but users may create more if they
choose?"  Or what?  I certainly see no reason to have more than 6 out
of the box...we don't completely use the ones we have now.  I can see
why users may want to create their own, however.

>  7. internationalization
>  8. define standard run level mappings (1 = halt, etc.)
> 
> Assuming nobody disagrees with the overall requirement, I'd like to
> hear what different ISVs and distributions on this list think about
> the 8 above items.  If any significant additions to the list of
> possible requirements are posted, I will post another requirements
> summary (this is the first summary, hence the #1).
> 
> I ask that everyone try to not discuss implementation details except
> as necessary to discuss the list of requirements.  ;-)

I don't think I stepped out of bounds above.  What I propose isn't
really a set of symbols, either.  The app would simply need to specify
which group it belonged to, which runlevels it wanted to live in, and
optionally which services it depended on (ie if it were a firewall
script it probably would need to live in low level service setup and
probably would depend on networking being started first).


--Donnie

--
   Donnie Barnes    http://www.redhat.com/~djb    djb@redhat.com   "Bah."
   Challenge Diversity.  Ignore People.  Live Life.  Use Linux.  879. V. 
                   If you pick it, it'll never get well.