linking statically against dietlibc: a blocker?

[Paul Wouters]

On Tue, 3 Oct 2006, Patrice Dumas wrote:

> 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).
>
> And it should be well understood that these are exceptions.

I would say that FC/FE is using glibc, not another c library, and that
packages build for FE should be linked against glibc.

There is nothing wrong with options to build differently, so one could do:
do: rpmbuild -ba foo.spec --define 'dietlibc 1' to get non-default
builds from FE sources.

But I don't think we should start using different c libraries for
random binaries.

Paul