Review Rules and staticly linked packages agains dietlibc

[Hans de Goede]

Michael Schwendt wrote:
> 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?
> 

Exactly, I agree 100% and I especially agree with the no numbers shown 
argument, I've asked for numbers on the efficiency increase before, 
where are those numbers?

Regards,

Hans