Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Package Themis Core with BoringSSL (#683)
* More accurate DEB dependencies Strictly speaking, libthemis depends on the OpenSSL library, not the "openssl" binary. The "openssl" package installs the entire binary along with its man pages, etc. Instead, it is sufficient to depend only on the library. The library package is typically called "libssl1.1", with an ABI suffix. The default OpenSSL library version differs between distros so we cannot write it in Makefile, but we should depend on the OpenSSL library from the particular distribution. If we were using debhelper, this would have been resolved for us automagically, but we are using FPM. Therefore we will use the dependencies of "libssl-dev" package as a proxy for the current default OpenSSL library name. This should be good enough. * More accurate RPM dependencies Similar to Debian/Ubuntu situation, the "openssl" package on RHEL/CentOS installs the "openssl" binary. The package with libraries only is called "openssl-libs", we should depend on that instead. RPM packages typically do not include ABI infromation in the name, though the distros here typically do not ship multiple ABIs of a library either so it's fine. * Changelog entry * Build BoringSSL package with suffix If we are building Themis with embedded BoringSSL, produce packages with "-boringssl" suffix in their names: - libthemis-boringssl - libthemis-boringssl-dev - libthemis-boringssl-devel Note that this affects only Themis Core packages. Other packages do not depend on the choice of the cryptographic backend and keep their names: - libthemispp-dev - libthemispp-devel - libthemis-jni - libphpthemis * Exclude OpenSSL from dependencies of BoringSSL flavor If Themis Core package is built with embedded BoringSSL, it does not depend on the system OpenSSL anymore. Do not include OpenSSL library and development packages in dependencies of "libthemis-boringssl" and "libthemis-boringssl-dev" packages. * Make OpenSSL and BoringSSL packages conflicting Since both flavors of Themis Core install effectively the same files, make them conflicting: - libthemis conflicts with libthemis-boringssl - libthemis-dev conflicts with libthemis-boringssl-dev This prevents simultaneous installation. The implementation is not the most beatiful one, but we need to make it symmetric as either package conflicts with the other one. * Alternative dependencies for non-core packages Both OpenSSL and BoringSSL flavors of Themis Core provide the same ABI and can be used interchangeably. Make sure that both can satisfy dependencies of libthemispp, libthemis-jni, and libphpthemis packages. Note, however, that libthemis-boringssl cannot be used with libthemis-dev and vice versa. Also note that in this case we need to keep the version specs in parentheses because --depends value is directly substituted into DEB's "Depends:" field. FPM will not add parthenses for us this time. * Accurate PHPThemis package dependencies Previously PHPThemis did not include in its dependencies at all. Make sure it depends on either OpenSSL or BoringSSL flavor of it, similar to the "libthemis-jni" package.
- Loading branch information