Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Use virtual package mechanism for BoringSSL package (#686)
* Use virtual package mechanism for BoringSSL package Why alternative packages are not good ------------------------------------- Alternative package dependencies are great, but they have several issues for the use case we need. First of all, 'boolean package dependencies' are not supported on CentOS 7 which we need to support. RPM >= 4.13 is required to build *and* install such packages correctly [1]. Unfortunately, CentOS 7 uses RPM 4.11 so we're out of luck here. [1]: https://rpm.org/user_doc/boolean_dependencies.html The second issue is that if some other package previously depended on, say, "libthemis (>= 0.13)", the new "libthemis-boringssl" cannot satisfy that depenency. It is able to, but the package manager will not allow it to be installed for it is not "libthemis". What is the alternative to them? (heh) -------------------------------- Alternative (boolean) package dependencies may work for our packages since we make them to, but they won't work for other packages. In fact, alternative dependencies are not the best solution here. We would like the BoringSSL flavor to be able to stand in for the OpenSSL flavor because it provides the same API and ABI. dpkg and RPM have a mechanism for this -- the "Provides" field in the package specs. "Provides", "Conflicts", and "Replaces" --------------------------------------- If BoringSSL package *provides* "libthemis" then it can satify the need for "libthemis" of any other package, like "libthemis-jni", for example. Similarly, "libthemis-boringssl-dev" provides "libthemis-dev". Note, however, that "libthemis" and "libthemis-boringssl" are still mutually exclusive so they need to conflict with each other. In fact, all flavors of "libthemis" conflict with each other and the same is true for the development packages as well. In addition to that, if we declare them as *replacing* one other, the package manager will be able to tell that it can remove the old conflicting package and install an alternative to it, without bothering the user. Caveats ------- FPM discards versioning information from "--provides" arguments. While RPM does not seem to have any issues with that, dpkg does have issues which break conflict resolution if the provided versions are not specificed. We have to insert DEB fields directly to fix this. Otherwise the users will see the following errors dpkg: dependency problems prevent configuration of libthemis-jni: libthemis-jni depends on libthemis (>= 0.13.0+xenial); however: Package libthemis is not installed. Version of libthemis on system, provided by libthemis-boringssl:amd64, is <none>. dpkg: error processing package libthemis-jni (--install): dependency problems - leaving unconfigured when installing packages that depend on "libthemis" when it is replaced by "libthemis-boringssl". Remaining issues ---------------- Although packages can replace each other, there are still some issues with that. For example, on Debian I am not able to cleanly replace both "libthemis" and "libthemis-dev" simultaneously with "libthemis-boringssl" and "libthemis-boringssl-dev", while it is still to do it one package at a time, if done in correct order. RPM on the other had is fine. Also, it is currently possible to install "libthemis-boringssl" and "libthemis-dev" simultaneously without conflicts. While technically it still works, this may be surprising for the users, especially if they try building something with static libraries. It would be nice to disallow such installation in some way. * Fix "libthemis" dependencies on some systems On some systems (e.g., Ubuntu 16.04) the "libssl-dev" package depends not only on "libsslX.Y.Z", but on other packages too ("zlib1g" in the casse of Ubuntu). The current spell for finding out the name of the OpenSSL library package does not take that into account, and this leads to incorrect command line passed to FPM. Improve the spell to react only on "libssl" packages, which there should be only one in the dependency list.
- Loading branch information
