Ville Skyttä wrote: > It's easy enough to change this and link the executables dynamically, and I > haven't bothered to get any numbers to check the upstream claim. But I > suppose the primary security reason against static linkage doesn't really > apply that much when the executable and the lib are results from the same > package build, so I thought I'd ask if there are strong opinions on whether > this would be a valid exception to the no static linkage guideline or not > (none here). I tend to agree that the primary reason for this is security and that claim is not as strong in this case. I have two thoughts to toss out: * Linking the utilities dynamically tests that dynamic linking works. mono w/ libmono on ppc caught this problem (although we're currently shipping that statically linked because F11 is too close and nothing else in-distro currently embeds the mono runtime :-( * If we allow this, reviewers and packagers will have to be careful about deciding whether the package really is the canonical place for the library. For instance, rsync builds against a private, slightly modified version of zlib. zsync does the same thing. These should not be allowed exceptions as the security concerns still apply. Ralf's point about saving disk space is also a negative. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging