From owner-freebsd-ports@FreeBSD.ORG Fri Jul 16 10:03:29 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFAAA16A4DD for ; Fri, 16 Jul 2004 10:03:29 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 921A643D1D for ; Fri, 16 Jul 2004 10:03:29 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-5.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34 (FreeBSD)) id 1BlPYr-0003Uh-To; Fri, 16 Jul 2004 12:03:28 +0200 Date: Fri, 16 Jul 2004 12:04:10 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Mike Makonnen From: Oliver Eikemeier In-Reply-To: <20040715150739.GA11628@rogue.acs-et.com> Message-Id: <7B900F95-D70F-11D8-8DBE-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: ports@FreeBSD.org Subject: Re: localpkg script changes X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2004 10:03:30 -0000 Mike Makonnen wrote: > 1. Ports startup scripts breaking: > [...] > As I see it now, ports scripts *are* broken because, among other > things, they expect .sh scripts to be sourced in a sub-shell. [...] > As far as I am concerned rc.d behaviour is that .sh scripts are > sourced in the current shell, and others in a subshell. All scripts, > be they base or ports should follow this behaviour. To have > inconsistent behaviour between base and ports scripts is a > bug IMO. The PR you cited mentioned something about changing the > suffixes, but I think that would be a gratuitous digression from > behaviour in NetBSD. > > In short: current ports scripts behaviour is broken and should be > changed as soon as possible instead of trying to patch rc.d/localpkg > to accept and propagate their brokeness through 5-STABLE. AFAICS fews scripts in /etc/rc.d use the sourcing mechanism. Your definition of brokeness seems very NetBSD centric too me, how about using a different extension on FreeBSD (.src for sourced rc :) ) and adding a `case' depending on OS to the mechanism? NetBSD could even merge this, when they want to. I can assure you that you open a major can of worms when you try to `fix' all FreeBSD ports, including introducing an incompatibility with 4.x. > 2. Starting base rc.d and ports rc.d scripts together from /etc/rc: > The last patch in the PR seems to be a fairly practical way of doing > this, but would require some broader discussion. I'm also a little > uncomfortable about it because mixing in ports daemons with base system > daemons in a way that is not deterministic at startup may have security > implications. It's fairly > easy for an administrator to audit the base system startup order, but > when you start introducing ports (third party applications of varying > quality) into the mix it becomes a lot harder to know if you are > introducing > a source of insecurity. This may or may not be a valid concern, but > this > close to 5-STABLE I think we should hold off on it. In anycase I think > this is a separate issue and should be dealt with separately. I think we should introduce this before 5-STABLE, especially since the current estimated time frame gives us enough room for testing. If you want to follow the NetBSD way, you have to add racoon, ports ppp daemons and other port startup scripts to /etc/rc.d, which IMHO makes no sense of FreeBSD. This is something that enables to use port features from the base system, replace base system functionality by ports or even move parts of the base to ports without any negative impacts. Besides, we finally have a way to get a proper startup order for ports scripts without using `000.'. It should be easily possible to either require a special keyword for ports scripts to get sorted before a certain point, or assure that most scripts are started after most of the base is up. I think this would bring us some desperately needed features, while `fixing' the ports scripts is a lot of work without added benefits. -Oliver