Debian is switching to EGLIBC | Hacker News Reader

Debian is switching to EGLIBC

blog.aurel32.net

47 pointstsally13 comments

Support for different shells (GLIBC only supports bash).

What exactly does this mean? How does a libc "support" a shell? I thought it was the other way around. Clearly tons (all?) of shells already run on glibc systems. Is this something that's only relevant for embedded systems?

The linked-to bugs just indicate that Ulrich Drepper wasn't interested in making the test suite or ldd work without bash.

And that he wouldn't accept already-completed patches to do so, and told their authors to maintain their own fork if they wanted to use other shells.

Basically, glibc includes bash-specific shell scripts. You probably can't build glibc without bash, and some glibc components (like ldd, as the blog post points out) require bash.

From the diff (http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/libc/nptl/Ma...) and this bug (http://sources.redhat.com/bugzilla/show_bug.cgi?id=9901), it looks like bash is hard-coded as the shell used for the test suite (and possibly other internal behavior, like spawning sub-processes).

Speaking as somebody who ports stuff to OpenBSD, it's a surprisingly common assumption in Linux programs that the standard shell is bash, when in fact it's not necessarily present on any other Unix. (sh, the bourne shell, is the default.)

While this sounds nitpicky, it's quite annoying to have problems testing a program because every single test case script has #!/usr/bin/bash hardcoded at the top. If it's using bash-specific extensions for scripting, that's understandable, but that's seldom the case.

'If it's using bash-specific extensions for scripting, that's understandable, but that's seldom the case.'

Are you sure? Bash-style functions and arithmetic subshells are pretty common. As long as they don't label the script with the Bourne interpretar (/bin/sh) then Bash scripting is fine.

I'm talking about incidental scripts included with programs for e.g. installation and regression testing, not scripts that encompass a lot of primary functionality. And, yes, it happens periodically enough to be considered a Linux-ism to watch for while porting.

Anything that moves power away from Ulrich Drepper and back to the community is a good thing. He is a poison to the open source community, and causes so much bad PR I'm amazed that he's still around.

Why is he still around, anyway?

Ulrich Drepper is a brilliant programmer and an expert on his field, but he cannot work with people. I figure that the former is the only reason why he's still around.

Richard Stallman apparently has the same reputation

Ahhh... an unfortunate - but all too common - collection of personality traits. I propose that those people should be given lots of power but not be promoted to package maintainers. Of course, it's open source, so it's not like we can decree this or anything, but it sure would make many open source projects easier to contribute to.

Of course, it's open source, so it's not like we can decree this or anything

He is employed by RedHat, so they're implicitly making the decision his working style is worth it.

But this is an example of open source at work -- people forked GLIBC due to, in part, dissatisfaction with Depper's (or Redhat's) working style and priorities.

Isn't that fork essentially a logical solution? If RedHat continues to pay Drepper for his work, he will still develop/maintain glibc. Meanwhile every valuable patch can be ported to eglibc (provided the licenses are compatible). It's a win-win scenario... community gains something and Drepper can still do what he does best in his sandbox.

Reply on news.ycombinator.com