
Debian is switching to EGLIBC - tsally
http://blog.aurel32.net/?p=47
======
drewr
_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?

~~~
silentbicycle
From the diff ([http://www.eglibc.org/cgi-
bin/viewcvs.cgi/trunk/libc/nptl/Ma...](http://www.eglibc.org/cgi-
bin/viewcvs.cgi/trunk/libc/nptl/Makefile?rev=8028&view=diff&r1=8028&r2=8027&p1=trunk/libc/nptl/Makefile&p2=/trunk/libc/nptl/Makefile))
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.

~~~
nailer
'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.

~~~
silentbicycle
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.

------
tophat02
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?

~~~
FooBarWidget
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.

~~~
tophat02
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.

~~~
brendano
_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.

~~~
viraptor
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.

