linking statically against dietlibc: a blocker?

[Denis Leroy]

Patrice Dumas wrote:
> Hello,
> 
> 3 packages submitted by Enrico are under review:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176581
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176582
> 
> Enrico linked these small daemons statically with dietlibc.
> 
> Other contributors disagree with this choice, but I think that the
> situation should be clarified once for all, and it should said
> whether this is a blocker or not.
> 
> My personal point of view is that linking statically (and against 
> dietlibc) shouldn't be a blocker if
> * the maintainer is aware of the security implications, and
>   that he has to follow the security issues regarding the package 
>   linked statically against and rebuild as soon as it is out,
> * there is a gain in term of efficiency (and potentially portability).

imo this should not be allowed unless it is a specific upstream 
requirement. I'm concerned with the complexity involved in introducing 
multiple competing C libraries in FE (duplicated security audit 
efforts), a choice that to me should be left to the upstream project 
rather than to the packager. Also I don't buy the efficiency argument: 
glibc is used by every single executable in a Fedora environment, and 
therefore is constantly in memory and hot in the cache. There should be 
a powerful argument to link against something other than glibc, and a 
faster startup time seems unconvincing.

-denis