linking statically against dietlibc: a blocker?

[Hans de Goede]

Denis Leroy wrote:
> 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.
> 

+1,

We have been over this before having dietlibc available prebuild in 
extras may be handy for people doing development for i386 embedded 
systems, but besides that it should not be used PERIOD.

Please lets not have this flamefest again (and again and again).

I say that Fesco or the packaging commitee should take a decission on 
this and then be done with it.

Regards,

Hans