Review Rules and staticly linked packages agains dietlibc

[Michael Schwendt]

On Fri, 24 Feb 2006 11:17:38 +0100, Enrico Scholz wrote:

> > IMO, dietlibc should be banned from Fedora. Its only purpose is to
> > circumvent the OS's libc for highly questionable reasons.
> 
> Efficiency is a "highy questionable reason"?

To be accurate with regard to the packaging guidelines on linking against
shared libraries they say: "should as far as possible". Linking shared
against glibc _is_ possible. So, this raises the question why another libc
implementation -- let's call it a competing implementation -- shall be
preferred in this case? Efficiency? That's one thing that worries me
during this discussion: What will be next? Somebody wrote that packagers
may decide on their own "what's best". Does this bring us back to a point
where packagers may decide for themselves whether to use default RPM
optflags or whether to get back to -O3 -funroll-loops and other forms of
"optimisation hell"? On the contrary, this thread has not discussed any
numbers that prove the efficiency gain. Instead, it has gone as far as
discussing the secureness of low-level C functions. So, once more, what is
the overwhelming reason for preferring a competing C library over the core
OS's C library?