This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Mon, Jul 31, 2000 at 05:58:31PM +0200, Thorsten Kukuk wrote: > On Mon, Jul 31, Jakub Jelinek wrote: > > > What's your suggested way of testing things sufficiently so that glibc 2.2 > > can be a reality soonish? > > I think a Beta distribution is a very good way how to get thousands of > > testers (which would not give it a shot otherwise) to test it. > > Yes, it is a good way. But we know that we will have binary incompatible > changes for 2.2 final (like sunrpc/IPv6). We have sunrpc/IPv6 disabled by a patch in the sources, so sunrpc/IPv6 particularly should not be an issue (ie. with the exception of svc_getreq_common; svc_getreq_poll; svc_max_pollfd; svc_pollfd which are @@GLIBC_2.2 there are no GLIBC_2.2 sunrpc symbols. This means no packages in the Beta use svctcp6_create and the like symbols, so when (anyone working on it??) / if they are added, nothing breaks. Also, if there were binary incompatible changes to IPv4 or core part of sunrpc, it would mean binary incompatibility with glibc 2.1.3 and thus the new symbols would have to go into GLIBC_2.2 version (and as Pinstripe packages are linked with those @ GLIBC_2.[0-1]*, again should not do any harm). I don't claim there is no possibility for problems here (what would be bad if a binary incompatible change was done against an already @@GLIBC_2.2 symbol), but I hope it will be ok. Jakub
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |