Aurelien Jarno wrote: > Except that package rebuild doesn't mean a new upload (e.g binNMUs).
Yes, it would be painful if many packages have bugs of this kind. Open source projects tend to check for this (and I've never run into it after using libc 2.13 for a while) but I could easily be underestimating how bad it is. What I meant is that packages rebuilt against libc from sid are generally targetted at wheezy. That would (one hopes) give a little time to test and fix them. > I am not convinced that the upstream fix is really the solution. As soon > as the package is rebuild, the problem will happen again. I think it's mostly meant as a workaround to allow people to keep using Flash and old binaries. Another big downside is making almost everything depend on libc6 (>= 2.14). Binaries built against glibc with the upstream fix wouldn't be usable on older systems. > Le 04/05/2011 09:05, Jonathan Nieder a écrit : >> E.g., how about adopting hjl's suggestion and making the >> behavior (temporarily) conditional on a LD_DONT_BIND_IFUNC_MEMCPY_TO_MEMMOVE >> environment variable? > > I don't really feel like enabling critical features depending on an > environment variable that might not be properly propagated in some shell > scripts. I'm not a huge fan of the envvar trick, but I think you read it backwards. Unlike hjl in the bug log, I was suggesting using the safe behavior when the envvar is not set. At worst a script using sudo or "env -i" would cause programs it calls to use memmove instead of memcpy. Unfortunately I fear testers would be unlikely to actually use such a variable. Even MALLOC_PERTURB_ is not as widely used as one would like, judging from the bugs it sometimes uncovers. So yes, back to the drawing board. Thanks for your thoughtfulness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
