[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Feedback on Ted T'so's initscripts proposal



   Date: Sun, 12 Mar 2000 08:19:31 -0500
   From: Jim Kingdon <kingdon@redhat.com>

   So you are planning to delete "Provides:" from the text?  I don't see
   anything in the current draft
   (http://www.debian.org/Lists-Archives/lsb-spec-0002/msg00015.html was
   the latest I found) which implies the above (yet :-)).

   Speaking of which, you planning to check this into CVS?

Yeah, on my todo list is to frobnicate it into SGML and get it checked
into CVS.  Then I got sidetracked by the nightmare which is SGML tools,
and so it didn't happen before I left for Australia.  It hopefully will
get checked in the next week or two.

   * sysadmins could still re-arrange the scripts manually.  Basically,
     Ted's draft doesn't say whether one uses links, or r2d2 (which puts
     scripts in init.d but uses a config file to specify which ones gets
     run, as I understand it), or some other mechanism.

Basically, yes.  The choice between implementations, whether they be a
traditional System V setup, r2d2, or a to be implemented, fully
parallelized execution system shouldn't be constrained by this proposal,
I personally think that if implemented, a parallel execution system has
a number of advantages, since a number of rc scripts don't require need
to be completed before allowing console logins, something which the
current scheme doesn't really allow.  (It can allow graphical login if
xdm is started earlier, but as far as I know most distributions don't
seem to do this).

   * Any thoughts on having "Requires-start" on the install_initd command
     line versus in the script?  The former kind of sounds like it could
     be a mess (especially if people are running install_initd manually
     rather than via a script), but it seemed worth at least asking the
     question.

I wanted to allow some system administrators to be able to use
install_initd to install and deinstall init scripts; that plus the
observation that what dependencies (networking, named, network
filesystems, syslog, etc.) a particular initd script requires are a
property of the initd script and aren't likely to change.  Hence,
encoding this information in the script itself seemed to be the cleanest
approach.

							- Ted


Reply to: