Date: Sat, 9 Nov 2002 11:18:13 +0000 From: Doug Rabson <dfr@nlsystems.com> To: Daniel Eischen <eischen@pcnet1.pcnet.com>, "M. Warner Losh" <imp@bsdimp.com> Cc: ataraxia@cox.net, current@FreeBSD.ORG Subject: Re: [PATCH] note the __sF change in src/UPDATING Message-ID: <200211091118.13041.dfr@nlsystems.com> In-Reply-To: <Pine.GSO.4.10.10211081806220.10745-100000@pcnet1.pcnet.com> References: <Pine.GSO.4.10.10211081806220.10745-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote: > On Fri, 8 Nov 2002, M. Warner Losh wrote: > > In message: > > <Pine.GSO.4.10.10211081205020.27766-100000@pcnet1.pcnet.com> > > > > Daniel Eischen <eischen@pcnet1.pcnet.com> writes: > > : All the ports are going to be rebuilt for the release anyways, > > : so this doesn't affect fresh installs, correct? It is only a > > : problem when mixing older 4.x and 5.0 libraries/binaries with > > : __sF-free libc (if I understand things correctly). > > > > The problem is that you cannot have 4.x packages and 5.x packages > > co-mingled on the same system. that's what I'm trying to fix.=20 > > You'd have to rebuild the 4.x packages before they are fixed. > > I don't think this is a show-stopper. Just recompile all your > ports or use the pre-built 5.0 packages. > > > : This is 5.0; it is a major release and there will be some flies > > : in the ointment. I say bite the bullet now -- don't wait. > > : If we want to provide an optional compatability hack to libc > > : so that folks can compile it with __sF support, then I think > > : that is better than leaving __sF in the release, perhaps > > : with a mktemp(3)-like warning if possible (?). > > > > You'd need a run-time warning for this to be effective. I'm not > > sure that ld.so can do this right now. > > Could you put __sF in it's own file, and put the error in > a .init section? We don't care about static binaries, right? > They shouldn't have a problem. > > > 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=20 the first time ever, which can't run old binaries. Sorry, that isn't=20 acceptable. The correct and robust way of doing things is to stop=20 creating binaries (in both 4.x and 5.x) that reference __sF, then wait=20 a full release cycle for the change to propagate. We can then remove=20 the symbol in 6.x.=20 In general, its a very poor idea to simply remove a feature that was=20 supported in the last release of a package. The normal route is to=20 deprecate (but still support) the feature in one release and remove it=20 in the next. --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211091118.13041.dfr>