Debian Switching From Glibc To Eglibc

ceswiedler writes "Aurelien Jarno has just uploaded a fork of glibc called eglibc, which is targeted at embedded systems and is source- and binary-compatible with glibc. It has a few nice improvements over glibc, but the primary motivation seems to be that it's a 'more friendly upstream project' than glibc. Glibc's maintainer, Ulrich Drepper, has had a contentious relationship with Debian's project leadership; in 2007 the Debian Project Leader sent an email criticizing Drepper for refusing to fix a bug on glibc on the ARM architecture because in Drepper's words it was 'for the sole benefit of this embedded crap.'"

Comments

Might be a good idea

[je ne sais quoi]

Speaking as a Debian user who has had some major upgrade problems directly caused by glibc, anything that's "more upstream friendly" is okay by me. I've had my system totally screwed by glibc problems before, so badly that the only thing I could think of to do was to reinstall (it was while installing on a new machine, so it was okay). Whenever I see that glibc in the upgrade list for apt-get upgrade, I get a little queasy to this day though, along with upgrading the locales package.

FINALLY

[Anonymous Coward]

Drepper has had this coming for many, MANY years.

He has pissed off practically everybody in the FOSS world at least once.

Good riddance.

I hope this ends up like the gcc/egcs thing a while back. In the end the old gcc was shut down and egcs was renamed back to gcc.

It would be for the best of glibc if this Drepper dude got removed from the project.

I still think we should organize a mud wrestling match between Ulrich and Theo.

Re:FINALLY

[emurphy42]

Drepper's complaint was that the fix would slow things down on other architectures. The counterarguments were (1) he was relying on an assumption that could be broken under other circumstances as well, and (2) a different version of the fix that would actually speed things up on all architectures. (I assume these things are correct because some version of the fix was eventually accepted.)

Re:FINALLY

[TheRaven64]

Sure he's a bit abrupt on the glibc dev list, but does any of that really interfere with his role as package maintainer?

Yes. When he refuses to incorporate the string manipulation functions that don't perform silent truncation, that's a security problem. Every BSD libc (including Darwin/OS X) has strlcat() and friends, but Drepper decided they were 'inefficient BSD crap'. A few projects, like OpenSSH, just include a copy of the ones from OpenBSD libc in their own code, but other projects over the years have just fallen back to strncat() and friends if the safe versions aren't available, and had security problems on GNU platforms that didn't apply elsewhere.

If you're going to refuse patches for no reason other than the fact that you're an idiot, then it is affecting the project you maintain and a fork is an excellent idea.

downstream from debian

[C0vardeAn0nim0]

downstream we have many, many distros now adays.

so, if this eglibc becomes the default, it'll end up being the default in pretty much all debian based distros like ubuntu, mepis, xandros, etc.

a repeat of the whole xfree86/x.org thing ?

For the greater good

[Rob Riggs]

That quote in the story is way out of context. Ulrich's words were:

Any change will negatively impact well designed architectures for the sole benefit of this embedded crap.

As the maintainer of GLIBC, he has to be the steward for the greater good of all users. And sometimes that means pissing off a vocal constituency.

Re:For the greater good

[Burkin]

He claims random crap like that all the time when he refuses to fix bugs.

Re:For the greater good

[LizardKing]

He's not fit to write C.

Which is probably why glibc source code looks like preprocessor soup.

Yay!

[Omnifarious]

I've been wishing for ages for maintainership to be taken away from Ulrich Drepper. Every single bug report I've seen submitted to him has been shot down for some stupid, insane reason, even when it's been accompanied by a patch. He's a bad maintainer.

One example, I submitted and update to an EBCDIC encoding used on IBM mainframes. The encoding had several choices for what should be encoded as the newline character. It wasn't clear which one should be used, but the z/OS system I was using had definitely chosen a particular one. Glibc had chosen a different one. I submitted a patch that changed it and Ulrich rejected it saying that there wasn't a standard and so my version was no more valid than the version that was in the library.

And, on another case, it was clear that the /etc/localtime was being read for each and every field that was being printed in strftime. This both caused things to be slow, and it also created a race condition if that file was changed. I recommended to the person who found the bug that he submit it. He did, and Ulrich rejected it for some bizarre reason I can't recall.

He is an awful maintainer, and I really hope the project is taken away from him by this fork.

Some of Ulrich Drepper's finer points

[bconway]

From TFA: 1 2 3 4