Learn more about these different git repos.
As the functionality provided by different SSSD back ends grows gradually, so does the list of the required packages and libraries grow. I think we have reached the point where it makes sense to package different providers as independent subpackages. This split might be beneficial for a number of third parties.
Tools such as realmd that configure the SSSD and are able to install required dependencies on the fly or based on provided options using PackageKit. A typical use case might be user that configures the SSSD to only act as a client for pure LDAP server -- that user would not be interested in installing all the dependencies required by the IPA back end (libipa_hbac, bind-utils) or even the new AD back end which might soon depend on Samba MS-RPC libraries.
Security auditors might (and do) try to find a minimal package set required to get the SSSD working. Providing them with a leaner set of dependencies would help their job.
milestone: NEEDS_TRIAGE => SSSD 1.9.1
priority: major => critical
rhbz: => 0
type: defect => task
owner: somebody => jhrozek
status: new => assigned
milestone: SSSD 1.9.1 => SSSD 1.9.2
patch: 0 => 1
We want this change in upstream and Fedora, but not RHEL-6.4.
Bumping out of 1.9.2 to avoid confusion even though there is a patch.
milestone: SSSD 1.9.2 => SSSD 1.9.3
Not critical for 1.9.3
design_review: => 0
milestone: SSSD 1.9.3 => SSSD 1.9.4
Not going to make 1.9.4
milestone: SSSD 1.9.4 => SSSD 1.9.5
This is a dependency of the sites lookup and the AD support in general. We need to have the AD provider in a separate subpackage to avoid pulling in Samba by default.
milestone: SSSD 1.9.5 => SSSD 1.10.0
milestone: SSSD 1.10.0 => SSSD 1.10 beta
resolution: => fixed
review: => 0
status: assigned => closed
Metadata Update from @jhrozek:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.10 beta
to comment on this ticket.