packaging a static library

Kevin Kofler kevin.kofler at chello.at
Wed Dec 30 21:02:30 UTC 2009


Daniel Drake wrote:
> OLPC has previously had a specific version of tomcrypt/tommath
> profesionally audited for security reasons. So we obviously want to
> stick with that version.

This is a bad idea and inconsistent with what Fedora is about. If you want 
that sort of things, you need to go back to maintaining separate OLPC 
branches. In Fedora, you're supposed to use the current version whenever 
technically possible.

> A few packages we have in Fedora currently use this frozen, audited
> version - we do so by shipping duplicate copies of that source code
> within the individual packages, rather than linking against the dynamic
> systemwide equivalents.

This is not allowed and the packages MUST be fixed ASAP (in fact they should 
never have passed review in the first place, this is a failure of our review 
process). (And if you refuse to fix it, I'll have to escalate it to FESCo.)

> As we're now looking at making another package which uses yet another
> duplicate copy of this code base I'm wondering if we can do it better.

Yes, just use the system version.

> Could I add a package, named olpc-bios-crypto-devel (a subpackage of the
> to-be-packaged olpc-bios-crypto), which installs the .a files for the
> audited libraries somewhere on the system?

Static libraries suck, your later suggestion of a shared audited version is 
better, but still the right solution is to just use the current version.

> Then the individual components that rely on this library (e.g. bitfrost,
> olpc-contents, olpc-bios-crypto) would have a BuildRequires dependency
> on olpc-bios-crypto-devel and build against the 'systemwide' static .a
> library files.
> 
> Or am I going too far against common packaging practice at this point?

Yes. Common practice in Fedora is to just use current software and forget 
about audits. Fedora is not a certified distribution.

> Any alternative suggestions?

See above.

        Kevin Kofler




More information about the fedora-devel-list mailing list