The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Which libc should we use in the future?

J.H.M.Dassen writes:
> > Ok guys 'n gals, there it is: H.J Lu has just officially released libc 5.4.7.
> > We are still using 5.2.18 (or glibc for the alpha).
> > 
> > So here is the "$50,000-Question": shall we upgrade to HJ Lu's libc 5.4.7
> > to stay up-to-date or shall we jump ahead of the pack and use glibc (=libc6)
> > providing only run-time compatibility as for libc4.
> 
> Let's stick with HJ for now. The linux-gcc developers are cooperating 
> with the GNU libc maintainers to make the transition as easy as possible.

This is the safest route right now.  

There is one catch with libc 5.4.x that people need to be aware of.
Programs built with it may not run with libc 5.3.x or lower.  What
this means is that once someone installs libc 5.4.x and programs built
with it on their system, they can't downgrade back to libc 5.2.18
without risking breaking things.  This could be a real problem for a
developer who needed to update a package in the stable tree because it
would need to be built with libc 5.2.18.  

The way I was going to handle this was to make a special libc5-dev
package using libc 5.2.18 which did not depend on the corresponding
libc5 run-time package (i.e. the symlinks for libc.so and libm.so
would be replaced with real files).  This way, a developer could
install this libc5-dev package when needed instead of the normal one
without having to downgrade the libc5 run-time package.

> Remember that glibc-1.9x is still officially unreleased.

... and is still changing.

> A glibc package now would be nice, as an addon to the existing system
> (e.g. gcc -bglibc ...) so we can take the time to prepare for the transition
> (similar to the /usr/i486-linuxelf/ approach used in preparing for ELF).
> 
> glibc has not been tested thoroughly enough for a production system, and
> the changes it brings (e.g. IPv6-ready incompatible [uw]tmp) will require
> changes in many packages. The slow transition we did to ELF had its 
> disadvantages, but at least it was done right: when we made the definitive
> move to ELF, the whole system worked, and there had been enough time to
> propagate many of the changes we had to make upstream.
>  
> Also, from my cursory reading of linux-gcc, it looks like it is still
> unclear if/when there will be a dynamic loader suitable for both libc 5 and 6.
> David?

It's looking like there will be separate dynamic linkers for each
library.  I don't think the glibc maintainers cared for my last
suggestion on how to handle both libraies with a single dynamic
linker.  At least not enough to even respond to it.

David
-- 
David Engel                        Optical Data Systems, Inc.
david@ods.com                      1001 E. Arapaho Road
(972) 234-6400                     Richardson, TX  75081

--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com