From owner-freebsd-arch@FreeBSD.ORG Sat Apr 26 23:58:09 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D662937B401; Sat, 26 Apr 2003 23:58:08 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1959243F3F; Sat, 26 Apr 2003 23:58:08 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <20030427065806003006c622e>; Sun, 27 Apr 2003 06:58:07 +0000 Date: Sat, 26 Apr 2003 23:58:04 -0700 (PDT) From: Doug Barton To: Scott Long In-Reply-To: <3EAB7486.2060107@btc.adaptec.com> Message-ID: <20030426231507.K657@znfgre.qbhto.arg> References: <20030426154030.M13476@znfgre.qbhto.arg> <3EAB12AC.8050707@btc.adaptec.com><3EAB7486.2060107@btc.adaptec.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD-rc@yahoogroups.com cc: freebsd-arch@freebsd.org Subject: Re: [FreeBSD-rc] Re: RFC: Removal of the old rc system from -current X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Apr 2003 06:58:09 -0000 On Sun, 27 Apr 2003, Scott Long wrote: > There's a big difference between, "dougb and friends no longer support > nor commit to rcOG, it's going away so don't use it" We've been saying this, although perhaps not as stridently as we could have, since we made NG the default 7 months ago. If they haven't caught the clue by now, I don't see how giving them more notice is going to help. > Invariably there are going to be people/vendors out there that are > abusing rcOG, have been lazy for the last 7 months and haven't adapted > their systems to rcNG, and will be highly cranky over rcOG disappearing. > Having a formal deprecation period gives these people some warning and > diminishes their ability to whine. =-) Once again, I have to ask you for a concrete example. If any 3rd party has scripts that run out of /usr/local/etc/rc.d, then they will continue to work just like they always have. If they have been abusing rcOG by actually editing the scripts that exist in /etc, their stuff is badly broken already, and the presence or absence of rcOG in the base isn't going to matter, since they are already depending on customized versions. If we were talking about a kernel API, I think that your request would be justified. But we're not. We're talking about an "interface" that has always provided well defined 3rd party support that will not be removed or changed, merely enhanced. The other thing to keep in mind is that unlike a kernel, or other interface, we have no power to actually take functioning rcOG scripts away from users. Even mergemaster doesn't delete files. People with wacky, broken stuff can keep running it that way forever for all I care. Also the stuff will still be there in CVS, just as unsupported and un-committed-to as it would be if we didn't cvs rm it. What I'm talking about is removing it from the default installation to avoid confusing new users, and to further reinforce the fact that it's gone away to anyone who still hasn't caught the clue. This will not cause any problems to those with existing rcOG installations that they depend on, or people who've converted to rcNG. > Adding a big "if [ "${rc_ng}" = "NO" ]; then echo "rc_ng=NO is > deprecated, unsupported, and will go away in the next release"; fi" to > the scripts allows us to cover our rears, makes everyone happy, and lets > you all off the hook for providing rcOG support. That's a good idea, I'm testing something like that right now, thanks. However, it will only be useful for people who upgrade /etc/rc*, which doesn't include the people you're most concerned about. Before you have another knee-jerk REaction to my proposal, please stop and think about how much different this scenario is than something like a kernel interface or binary. Then please try to come up with a concrete example of how things will break if the code is cvs rm'ed. I'm betting that you can't. :) Doug -- This .signature sanitized for your protection