From owner-freebsd-current@FreeBSD.ORG Sat Jul 31 17:20:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD80416A4CE; Sat, 31 Jul 2004 17:20:59 +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 74E2A43D64; Sat, 31 Jul 2004 17:20:59 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from dhcp-14.local ([172.16.0.14] helo=dhcp-11.local) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.41 (FreeBSD)) id 1BqxXU-000GDm-3x; Sat, 31 Jul 2004 19:20:58 +0200 Date: Sat, 31 Jul 2004 19:22:14 +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: <20040731155822.GB35674@rogue.acs-et.com> Message-Id: <2A78201C-E316-11D8-9C56-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-rc@freebsd.org cc: current@freebsd.org Subject: Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2004 17:21:00 -0000 Mike Makonnen wrote: > [...] > Ok, can you do the following then: >>> >>> 1. When you (portmgr) are ready put back the rc.d/localpkg changes >>> 2. Put the ordering of ports scripts with base system >>> scripts behind an rc.conf(5) knob, and modify your patch so both >>> /etc/rc and /etc/rc.d/localpkg do the right thing depending on >>> whether >>> it's on or off. >> >> I suggest changing the extension for sourcing scripts to `.rc' and >> ignore `.sh' scripts in rc/rc.shutdown. The unmodified localpkg >> should handle these. > > As I have already said, this is a gratuitous digression to support > buggy rc.d ports script who's bugginess has only existed on > 5-CURRENT up to now. New features might break existing stuff, which doesn't imply that have been buggy. Usually you do an estimation of effort versus gain (at least that is what I usually do), and decide what is more promising to bring you forward. I made two proposals: Either - allow new ports scripts to participate in rcorder(8), but disallow sourcing of scripts in /usr/local/etc/rc.d. Keep the historical difference that `.sh' scripts in /etc/rc.d are sourced, while `.sh' scripts in /usr/local/etc/rc.d are treated as old-style. No fixing will be necessary, but ports have to be changed to use the new functionality, supported by code in bsd.port.mk. Old or installed packages continue to work as usual. or - allow new ports scripts to participate in rcorder(8), and change the extension for sourcing of scripts to `.rc'. All `.sh' scripts will be treated as old-style, no matter whether they are in /etc/rc.d or /usr/local/etc/rc.d. Two scripts in /etc/rc.d (early.sh and rcconf.sh) have to be renamed, but no further fixing is necessary. Ports have to be changed to use the new functionality, supported by code in bsd.port.mk. Old or installed packages continue to work as usual. As far as I understand your proposals are: - put the localpkg commit back (which does rcorder(8) in ports, but not system-wide, so starting ports services early is still not possible) and let portmgr deal with the breakage - source rc.d `.sh' conditionally on a configuration parameter in either /etc/rc or localpkg, and do rcorder(8) depending on that parameter. ~ 100 ports have to be fixed and tested so that they will work correctly with the new semantics, and 5.0, 5.1, 5.2 and 5.2.1 are required to upgrade. New systems can not use old packages and have to upgrade installed ones. > Since, you and I don't seem to agree on this issue and since we both > don't seem to be restating the same things over and over againg. > why don't we refrain for replying to this thread unless we have > something > new to add? Perhaps it would be beneficial if we summarize our proposals, so that we can have something like a ballot or ask re@ for their opinion. You might want to correct my summary of your proposals, since I'm sure I misunderstood some of your arguments. -Oliver