Date: Sun, 12 Mar 2000 08:19:31 -0500 From: Jim Kingdon <[EMAIL PROTECTED]>
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
