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, andthat 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