glibc fork, to some extent

Lennart Sorensen lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Wed May 20 18:05:01 UTC 2009


On Wed, May 20, 2009 at 01:57:42PM -0400, D. Hugh Redelmeier wrote:
> I meant that the system as a whole (GLIBC + fork, sort of) doesn't
> seem stable.  I can see several possible outcomes:
> 
> - EGLIBC diverges (after all, tracking is hard work and actually may
>   reduce the value of EGLIBC).  Both projects have a large enough
>   niche to survive

Well the current goal appears to be to track glibc's sources but to
include patches that upstream glibc is refusing.  They appear to have
no intension of forking and going their own way entirely.

> - EGLIBC or GLIBC ends up being where the action is.  The other
>   whithers.

Well as long as eglibc is tracking glibc it would be in everyones
interest to get as many patches as possible moved into glibc just to
keep the differences minimal.  That goal might keep both going just fine,
and who knows some day the need for eglibc might go away.

> Note that the main GLIBC maintainers are at Redhat.  This detail might
> matter in several ways.

Perhaps.  I suppose they might some day care about something other
than desktops and servers on x86, in which case they might fire the
uncooporative maintainer.  Unfortunately redhat doesn't seem at all
interested in other markets.

-- 
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list