https://bugzilla.redhat.com/show_bug.cgi?id=1310092 --- Comment #43 from Ralf Senderek <fedora@xxxxxxxxxxx> --- (In reply to Peter Robinson from comment #37) > I have concerns about the bundled cryptlib: ... > Why was this classified as "Not applicable"? I don't see why cryptlib > shouldn't be shipped separately [2]. Was there a FPC ticket for this > exception? > [-]: Package contains no bundled libraries without FPC exception. I'd like to explain why cryptlib as a bundled library does not violate the packaging guidelines and why Richard's original classification as "Not applicable" is correct. Under the heading "Bundling and Duplication of system libraries" the packaging guidelines state the following: Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. All packages whose upstreams allow them to be built against system libraries must be built against system libraries. All packages whose upstreams have no mechanism to build against system libraries may opt to carry bundled libraries, but if they do, they must include Provides: bundled(<libname>) = <version> in their RPM spec file. In addition, packages whose upstreams have no mechanism to build against system libraries must be contacted publicly about a path to supporting system libraries. If upstream refuses, this must be recorded in the spec file, either in comments placed adjacent to the Provides: above, or in an additional file checked into the SCM and referenced by a comment placed adjacent to the Provides: above. The cryptobone and cryptlib are not separable. Even if a separate cryptlib package existed (which is not the fact) the cryptobone could use it in principle, but as the cryptobone is based on only a very small part of cryptlib, essentially the symmetric encryption enveloping only, and because reduction of complexity is one of the cryptobone's main goals, the whole point is to be able to link against a minimalistic version of cryptlib, maybe under a different name like libcl-mini.so instead of libcl.so. Now, we don't have this separate cryptlib package yet, and the cryptobone cannot be built against a system library. And if it could, the reduced mini library is a better choice from a security point of view. At the moment there is no alternative to bundle cryptlib with the cryptobone. "In addition, packages whose ..." The cryptobone package has no mechanism to build against a system library called libcl.so. I have made it clear (Comment #34 and devel list) that I (as the cryptobone upstream) want to build a separate cryptlib, so that linking is possible. I don't refuse to do that (as a packager). But when this library comes into existence the mini version as a bundled library is the next thing to do and to do it right takes time. If it helps I'll put this explanation as a comment into the spec file, but the cryptobone should not be blocked for this reason. Ralf Senderek -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/package-review@xxxxxxxxxxxxxxxxxxxxxxx