> an Bug #176579 I have a review, where soneone will published a > package with programs which are staticly linked agains the > dietlibc. > > Becouse I'm unsure about the packaging guidelines I want hear the > mind of other contributors on the list. It seems to be aginst the packaging guidelines. However it is a very specific case where static linking is advocated for speed reasons. If I am not wrong, the reasons to link dynamically because of the implementation of some glibc functions doesn't hold. However the security issue is still there. So, in that precise case, the choice is between security and efficiency. I see 2 possibilities 1) add a benchmark to the review (speed measurement for both cases, and memory footprint) that demonstrates a clear win with static libs. or 2) make two packages or 2 executables in the same package, one with the static and the other with the shared, and give the original name to the shared, and call the other by a name that helps understand that it is statically compiled. In any case if in the end there is something statically linked it should be advertised in the installed files (in a README or anywhere else). -- Pat -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
