On Friday 08 November 2002 11:13 pm, Daniel Eischen wrote:
> On Fri, 8 Nov 2002, M. Warner Losh wrote:
> > In message:
> > <[EMAIL PROTECTED]>
> >
> > Daniel Eischen <[EMAIL PROTECTED]> 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.
> > 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
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.
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.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Phone: +44 20 8348 6160
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
