libc5 policy decision
> When will you be making the libc5 decision?
> It would be nice to start Rex with the right one when it gets frozen.
Here is the decision. Libc 5.4.7 will be used with the _OLD_ allocator
in 1.2 .
The _NEW_ allocator will be made available in a separate library, and
people who want the increased performance of the new allocator will be
able to set LD_PRELOAD=/lib/libNewAllocator.so.5 (change the name as
appropriate) in their .login or .profile scripts, etc. Packages
should be tested with the new allocator, but not linked in such a way
that they demand it. This library will be made an empty stub in 1.3 so
that it does not collide with LIBC 6. 1.3 will provide libc.5.4.7 and
the old allocator for compatibility with old applications, and LIBC 6
with whatever allocator it contains for everything else.
I am aware that this is sub-optimal, and there's the esthetic problem of
holding back the library to make up for broken applications. I would not
make this choice if the release was to have an infinite lifetime.
Can you get the above implemented in time?
Pray tell, does the allocator in GNU LIBC 6 have anything to do with
either of the allocators in libc 5?
Thanks
Bruce
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: