I'm getting a dependency loop when building on FreeBSD 13. net/openldap24-client -> security/cyrus-sasl2-gssapi -> krb5 This appears to be caused by GSSAPI being enabled, and I have no idea where the best place is to actually fix this loop.
It seems that this needs to be solved by breaking up the krb5 port into multiple packages; I think the only component that really uses LDAP would be the KDC (+bjk@ who is the expert), so we can potentially have something like: krb5-client -- programs that are used to authenticate against Kerberos, libkrb5, etc. cyrus-sasl2 et al should depend on krb5-client, and with this ; krb5-kdc -- krb5kdc, etc., potentially depend on openldap; krb5 -- umbrella port and possibly also for Heimdal? BTW -- Ryan, in r355724 (bug 189470) we added the dependency to the GSSAPI plugin, but a quick glance at the code suggests that OpenLDAP don't really invoke anything from the library directly, and my understanding is that the dependency here is mainly a "serving suggestion", in other words, with the SASL enabled OpenLDAP, installing cyrus-sasl2-gssapi would make GSSAPI work for OpenLDAP without need of rebuilding with the "GSSAPI" option, is that correct?
(In reply to Xin LI from comment #1) We have three versions of krb5 + a -devel port. That would be messy. LDAP is not a default option. Leave it off and there is no dependency loop.
Do not turn LDAP option on when defining the GSSAPI option in openldap24-server.
I believe defining WANT_OPENLDAP_SASL=yes in make.conf makes all of this do the right thing. You want openldap24-sasl-client, not openldap24-client.
Nevermind, it looks like the sasl-client port was deleted two days ago.
Also as a reminder, because I've been bitten by this years ago, when building ports by hand, enabling options in different ports that make port A depend on port B which depends on port C, which depends on port D which in turn depends on port A, is a bear to diagnose and is the cause of no end of grief. Been there done that. It's no fun. I think we need a facility in pkg or in ports that detects these kinds of loops. Detecting port A depends on B depends on A is easy but longer chains are difficult to detect.
> I think the only component that really uses LDAP would be the KDC Yes, that's correct (both krb5kdc and kadmind processes, which are the KDC processes). The interaction between krb5 and LDAP is always a bit exciting to explain, because there's the option to have LDAP use kerberos for authentication, and the option to have krb5 use an LDAP directory as its database backend. Combining the two is prone to circular dependencies (both at runtime and at build-time) and is generally not something upstream krb5 recommends. It is technically possible to do it (by using a non-kerberos authentication scheme for the KDC to authenticate to the directory), but very much an expert configuration.