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