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? -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
