From owner-freebsd-ports@FreeBSD.ORG Tue Feb 24 11:34:26 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 9AD7516A4CE for ; Tue, 24 Feb 2004 11:34:26 -0800 (PST) Received: from smtp1.netcologne.de (smtp1.netcologne.de [194.8.194.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B53D43D54 for ; Tue, 24 Feb 2004 11:34:26 -0800 (PST) (envelope-from tmseck-lists@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-213-196-228-160.netcologne.de [213.196.228.160]) by smtp1.netcologne.de (Postfix) with SMTP id C9ED438B83 for ; Tue, 24 Feb 2004 20:34:22 +0100 (MET) Received: (qmail 1212 invoked by uid 1001); 24 Feb 2004 19:34:23 -0000 Date: Tue, 24 Feb 2004 20:34:01 +0100 From: Thomas-Martin Seck To: "Scot W. Hetzel" Message-ID: <20040224193401.GB717@laurel.tmseck.homedns.org> References: <20040223212225.1766.qmail@laurel.tmseck.homedns.org> <068d01c3fa65$e5eaff50$cebe7726@westbend.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <068d01c3fa65$e5eaff50$cebe7726@westbend.net> User-Agent: Mutt/1.4.2.1i Organization: private site in Germany X-PGP-KeyID: DF46EE05 X-PGP-Fingerprint: A38F AE66 6B11 6EB9 5D1A B67D 2444 2FE1 DF46 EE05 X-Attribution: tms cc: freebsd-ports@freebsd.org Subject: Re: OPTIONS, LATEST_LINK, and RCng 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: Tue, 24 Feb 2004 19:34:26 -0000 * Scot W. Hetzel (hetzelsw@westbend.net): > From: "Thomas-Martin Seck" > While, it will work, it causes the port-maintainer double duty, as they have > to maintain both the rcNG and the rcOLD portions of the script. Just fully I am the squid maintainer and I can assure you that there is no duplication of work in there. The rcOLD part was rewritten to reuse the variables that already had to be declared in order to actually use rcNG. And frankly: once these scripts work, they are hardly ever touched again. > convert your script to rcNG as we want to eventually get rid of all the > rcOLD scripts. The rc_subr port is just a transition aid to allow these > scripts to run on pre-rcNG systems. Well, the script we are talking about is an rcNG script. It is an rcOLD script too. It adapts to its environment without needing to pull in rc_subr. The only problem is that its overly friendly to rcNG and tries to pull in $PREFIX/rc.subr. That part will be removed. Otherwise I am not too happy to be advocated into rcNG, since I respect it and just ask for my decision to maintain compatibility between rcNG and rcOLD to be respected, too. > Before I submited the patches to bsd.port.mk for USE_RC_SUBR and provided > the port for rc_subr. I was looking at the NetBSD tree to see how they had > transitioned from their old rc system to their new rc system (rcNG). They > used a mix of both rcOLD and rcNG. And I started converting my scripts to > follow the way NetBSD did it. Then I looked at it again, and realized that > these scripts would need to be in the tree forever. Also when anyone brings > a new port in and it needs an rc.d scripts, it would also require them to > use a mix of rcOLD and rcNG, so that they would stay compatible with > previous releases. I determined that this mix of rcOLD and rcNG scripts > wasn't acceptable and came up with our current way of creating pure rcNG > scripts. Well, just because you do not like that it does not make it bad per se. I have no problem with providing compatibility for some amount of time. When the ports collection will only support systems that are rcNG - and I bet this time will come sooner or later - there is still time to remove compatibility hooks. Why put yourself under pressure just for aesthetic reasons? To be honest: when this discussion got fully engaged I was tempted to remove all rcNG stuff from squid.sh just to annoy the rcNG evangelists. My intention is to use rcNG where appropriate and fall back to rcOLD. I agree that using rcNG on systems with rc_subr installed without explicitly saying so by registering a dependency on rc_subr can be a POLA violation (though not as gross as some people liked to make it, since the effect is documented in squid.sh and I expect the admin to read the start scripts) and I will remove that part as I already said. > No, pulling in sysutils/rc_subr solves more problems than you realize. > > 1. It provides a common set of functions available to all rc.d > scripts (checkyesno, load_rc_config, run_rc_command, ...) > 2. It provides a common set of commands available to all rc.d scripts > (start/stop/restart/[status/poll]/[extra commands]) Yes, rcNG is nice since it unifies a lot of stuff that currently exists in various home-brewn variations in the tree. Once again, I like rcNG, just for the archives. I do not like the USE_RC_SUBR know. Why? It still provides no incentive for a port maintainer to actually convert his/her script when he/she does not bother about rcNG, since on pre-5 it will still work. There is now way to "get rid of" rcOLD scripts this way as long as there are still pre-5 systems out there. But instead of making sure that all port startup scripts use rcNG when it will be the default, talking maintainers into "USE_RC_SUBR, it will make the world a better place" has created a situation where scripts have prematurely been converted to rcNG without offering any compatibility to the rc mechanism in -STABLE's base system thus needing to pull in yet another dependency. As said already, I tend to avoid pulling in dependencies when I can do without. Even more so when their only incentive seems to be evangelism, since evangelism tends to annoy me really quickly. > The placing of the scripts in their proper order is the job of /sbin/rcorder > (only on 5.x+). Rcorder functions by reading the comments in a rc.d script > for specific keywords in order for it to determine in which order to place > the script. Currently, rcorder is not being used on -Current to start the > ports startup scripts because only a small portion of them have been > converted. I really don't like the term "converted". rcNG awareness (upwards compatibility so to say) really is sufficient IMO and I am quite happy with squid being able to play in both leagues without forcing anything upon the user. Whether you like it or not, it works. > NOTE: rcorder of the ports startup scripts is planed for -Current, but they > are waiting for the ports scripts to be converted. I'd be happy if the existing scripts were made to be rcNG compatible instead of blindly rewriting them to be rcNG only and thus needlessly forcing yourself to USE_RC_SUBR on pre-5 because otherwise the script would just be broken.