Description of problem: In sssd-1.5.x, one could choose to either use libcrypto or mozilla-nss as crypto backend. In sssd-1.8.0, the respective PKG_CHECK_MODULE calls no longer have an else-case, which means both libcrypto and mozilla-nss are required for running configure, even though only one is going to be used during compilation. (Makefile.am still has if HAVE_NSS/...) Version-Release number of selected component (if applicable): sssd-1.8.0 How reproducible: Build sssd in an environment where Mozilla NSS is not installed. Actual results: checking for NSS... configure: error: Package requirements (nss) were not met: Expected results: Ignore NSS if not present and move on to attempt using libcrypto. Additional info:
Upstream ticket: https://fedorahosted.org/sssd/ticket/1247
Jan, do you use the libcrypto back end? What is the reason for using it over the mozilla NSS back end? The mozilla NSS back crypto back end is the only one the upstream really supports. The libcrypto back end was a community owned nice-to-have feature, but frankly, we don't really test or use it and therefore we have disabled the libcrypto backend during the 1.6.0 development. It's better to disable the code altogether than ship something that just bitrots..
Nothing in particular. I just forward-moved openSUSE's sssd 1.5.x package (which used --enable-crypto) to now use 1.8.0. Changelog does seem to mention something... Wed Mar 31 07:57:25 UTC 2010 - rhafer - Updated to 1.1.0 - Backported libcrypto support from master to avoid Mozilla NSS dependency [Pulls in sqlite3, uses c++ and has no sense of library versioning—Dunno. Maybe it's just considered evil? :)
In Fedora, there is no reason to support other crypto backends than Mozilla NSS. Please use https://fedorahosted.org/sssd/ticket/1247 to track upstream requests for support of libcrypyo.