From owner-freebsd-current Sat Nov 9 8:28:43 2002 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 CA5A637B401 for ; Sat, 9 Nov 2002 08:28:41 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51C5543E3B for ; Sat, 9 Nov 2002 08:28:41 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id gA9GSEH7017517; Sat, 9 Nov 2002 11:28:14 -0500 (EST) Date: Sat, 9 Nov 2002 11:28:14 -0500 (EST) From: Daniel Eischen To: Doug Rabson Cc: "M. Warner Losh" , ataraxia@cox.net, current@FreeBSD.ORG Subject: Re: [PATCH] note the __sF change in src/UPDATING In-Reply-To: <200211091118.13041.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 9 Nov 2002, Doug Rabson wrote: > On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote: > > On Fri, 8 Nov 2002, M. Warner Losh wrote: > > > This is not a fly in the pointment, but rather a major > > > incompatibility that makes it impossible to have a reasonable mix. > > > > If it's really a hassle for folks, then just provide the > > optional compatability hack and make them rebuild libc. > > Or provide a pre-built version that doesn't get installed > > by default. > > So what you are saying, basically, is that we should ship a release, for > the first time ever, which can't run old binaries. Sorry, that isn't > acceptable. The correct and robust way of doing things is to stop > creating binaries (in both 4.x and 5.x) that reference __sF, then wait > a full release cycle for the change to propagate. We can then remove > the symbol in 6.x. If you put an optional compatibility hack in libc, then folks can still use it, plus they will be informed that it is going away at some point. I don't think removing it from is good enough. Unless there's a way of putting out an error message at run-time, we need some other way of being a little bit of a nuisance. > In general, its a very poor idea to simply remove a feature that was > supported in the last release of a package. The normal route is to > deprecate (but still support) the feature in one release and remove it > in the next. Do kld's from 4.x work on -current? Just curious -- I don't really know. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message