From owner-freebsd-current Fri Sep 8 7:47:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 30E3337B423 for ; Fri, 8 Sep 2000 07:47:32 -0700 (PDT) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 13XPQx-000FVU-00; Fri, 08 Sep 2000 16:47:15 +0200 Date: Fri, 8 Sep 2000 16:47:15 +0200 From: Neil Blakey-Milner To: Matthew Thyer Cc: current@freebsd.org Subject: Re: /usr/local/etc/rc.d and /etc/rc.d Message-ID: <20000908164715.A59499@mithrandr.moria.org> References: <39B8E865.B77012B@camtech.net.au> <20000908153421.A58134@mithrandr.moria.org> <39B8F928.C9F4339@camtech.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39B8F928.C9F4339@camtech.net.au>; from thyerm@camtech.net.au on Sat, Sep 09, 2000 at 12:05:20AM +0930 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat 2000-09-09 (00:05), Matthew Thyer wrote: > > > Stop scripts will be a symbolic link to their startup script > > > counterpart (and would simply not be executed if the K* file doesn't > > > exist). Symbolic links make it clear they are the same script. > > > > I don't see the point. > > The point is that people are worried about scripts that aren't aware > of the "start" and "stop" argument trying to start apps again at > shutdown time. With my scheme, the script wont be executed at shutdown > time if the K* script doesn't exist. If it's there, it gets executed. If it's there, it was put there. If it was put there, it'll have support for "start" and "stop". If an administrator puts a script in there that does the wrong thing, that's his fault. He could use the fall-back rc.local method. We needn't support stupid behaviour by complicating the matter. > > > Scripts would be executed in alphabetical order (after the S or K) > > > so the sysadmin has control over the execution order which is > > > important. > > > > I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at > > http://people.FreeBSD.org/~eivind/newrc.tar.gz) > > I haven't looked at this yet but off the top of my head, a dependency > based system sounds overly complicated (consider ports authors) and > unecessarily different from other systems. I am considering port authors, and I think that dependency-based systems will be _much_ better for them. Thanks for bringing it up. # before zope # before apache # after networking # after nfs is much better than: S10.networking.sh S20.nfs.sh S40.zope.sh S45.apache.sh and then figuring to use S43.foo.sh. > > > I'd also really like at least named and perl to be removed from the > > > base system but that's another thread. > > > > I'll comment when you bring it up. Warning: perl is necessary for > > kernel builds. > > I know but I'm pretty keen on awk and would like all the perl dependencies > to be re-written with awk or other tools as I dislike FreeBSD being > dependent on such a beast as perl which should only exist as a port. > Just look at the pain of getting perl 5.6.0 into the system. I know the > perl lovers will hate me but I thinks its worth having some ugly awk to > get away from elegant perl being required in the base system. I'm not particularly attached to perl, but it has a convenience in some sections, like ports, that is unmatched by sed and awk. Note the excessive use of "perl -i -pe 's/foo/bar/'" for in-place substitution. I've asked on at least two occasions for a simple, easy-to-use, thing to do it without doing a two-liner that copies to another file, and then replaces the old file with the new file. > I'd go further to say that the whole base OS needs to be more modularised > ala Solaris and Linux especially since we dont have an established binary > patch process. Its pretty hard to sell FreeBSD to my work masters when the > only patch method is source code patches or a complete rebuild of -STABLE > or just wait until the next release. A more modular system could be > upgraded more easily. I agree. I'd suggest you check out the freebsd-libh mailing list, and ask there about how to check out the libh sources. Your contributions to the libh project will aid development of the next-generation package management and installer. Neil -- Neil Blakey-Milner Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message