From owner-freebsd-ports Thu Sep 21 08:41:01 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA09657 for ports-outgoing; Thu, 21 Sep 1995 08:41:01 -0700 Received: from healer.com (healer-gw.Empire.Net [205.164.80.204]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA09639 for ; Thu, 21 Sep 1995 08:40:49 -0700 Received: (from gryphon@localhost) by healer.com (8.6.11/8.6.9.1) id LAA00321; Thu, 21 Sep 1995 11:40:25 -0400 Date: Thu, 21 Sep 1995 11:40:25 -0400 From: Coranth Gryphon Message-Id: <199509211540.LAA00321@healer.com> To: patl@asimov.volant.org, pechter@shell.monmouth.com Subject: Re: ports startup scripts Cc: ports@freebsd.org Sender: owner-ports@freebsd.org Precedence: bulk From: patl@asimov.volant.org > SVr4 was supposed to merge the two camps again by incorporating the > advantages of both systems. It fell down a bit in the areas where > both provided equivalent functionality in incompatible ways. And If you say so. Personally, I think SVR* fell down a lot in quite a few things (personal bias, but that is why I run BSD systems :-) > |> (Actually the capability to support both ways wouldn't be bad here... > |> how about keeping the old BSD init method as an option) > If that can be done easily and cleanly, I'd go for it. Yep, but is it worth the effort to get two working configuration utilities that understands both methods, let alone the work of getting the kernel to support both methods. Keep it simple. If we want to go with a run-level concept, then let's figure out what WE want, based upon what SysV does, but not just clone them. > |> Agreed... it looks like the argument comes down to NIH and that SysV's > |> startup complicates things more than the BSD /etc/rc /etc/rc.local does. > I still think that complication is more apparent than real. In some ways, > it has actually made things easier by making some of the decisions more It also tends to make finding something easier. If we are going to implement a run-level subdir startup, let's make it as un-complicated as possible. > Exactly. And the SVr4 method makes life -MUCH- easier for anyone building > an installation package for add-on software. Scripts to safely modify > rc or rc.local have to make some scary assumptions... That's its biggest advantage. > |> I think we should go the SVR4 route and I'm willing to document it... > I'll support you all the way. (I'll offer to help, but I'm not sure > how much use I can be in this.) Sure, I'm helping with the 2.2 sysconfig issues anyway. Let's just get a clean defined framework BEFORE we start implementing anything (1/2 :-) -coranth ------------------------------------------+------------------------+ Coranth Gryphon | "Faith Manages." | | - Satai Delenn | Phone: 603-598-3440 Fax: 603-598-3430 +------------------------+ USMail: 11 Carver St, Nashua, NH 03060 Disclaimer: All these words are yours, except Europa... -Pat