On Sun, Nov 03, 2002 at 09:13:33PM -0500, Jeff Bailey wrote: > On Sun, 2002-11-03 at 20:24, Daniel Jacobowitz wrote: > > > I object to not adding the patch. Just like our other compatibility > > patches, these binaries are a fact of life; we should prevent exposing > > the symbols at _link_ time, but there's no benefit to us in hiding them > > at runtime. > > The other compatibility patches are design to help programs that were > following the rules and that broke. This patch is designed to help > programs that were badly written. Will we be expected to maintain the > internal structures when they change, too? > > In this particular case, we gain nothing by adding this patch (the > various upstream authors recognise that they shouldn't have used that > function and are patching their programs) - and simply postpone the fact > that people have to replace these programs. Eventually the internal > interface will change - and it will probably just quietly segfault or > cause security problems instead of clearly saying that the program has > problems. > > I think we should simply make sure that Sarge's release notes indicate > that certain commercial programs (Java, WineX) had been incorrectly > using the C library and may need to be upgraded to keep them running.
__libc_waitpid's hiding is not interface-related, it's namespace-related. There are no changing interfaces involved, and it's clear that we can safely continue to export it unless there's a major change. __libc_fork similarly. If we make the symbol unavailable at link time - there's plenty of examples of this in glibc - then bad binaries can no longer be built on Sarge; then a release later we can stop supporting them. I believe that the only fair thing for our users is to allow a transition period. This is the first release which enforced the namespace rules; it was not very clearly documented before. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
