Created attachment 248412 [details] patch the security/krb5 LDAP option probably shouldn't be enabled by default because this can create dependency loops if OpenLDAP or Cyrus is built with MIT Kerberos. however, it's still useful to provide a version of Kerberos with LDAP support for people who need this. this patch adds new slave ports, krb5-ldap, krb5-ldap-121, and krb5-ldap-120 which build with LDAP enabled.
for context (and to justify this change): i'm trying to set up a backup KDC on a small arm64 system (RPi) which is too slow to build packages itself, i don't have any other arm64 systems i can build on, and since poudriere cross-building is mostly broken these days due to Rust, that means i'm relying on pkg.freebsd.org's binary packages. so, having a binary package for krb5-ldap would allow me to make progress on this.
How about we use flavors instead of subpackages? This would be a less intrusive change to the ports tree, keeping the change within teach Makefile. I don't think bapt@ intended a proliferation of slave ports when creating the subpackages feature. I see subpackages as a vehicle to split krb5 into server and client. That is the plan when the subpackages feature matures a little.
i didn't use subpackages for this (even though i think this would be a good example of a subpackage, since kldap is a loadable .so) because of the issues that resulted in subpackage adoption being paused, so this is just a normal slave port that builds a full package. i can redo this to use flavours instead though - i assume the flavours should be called "default" and "ldap"?
Created attachment 248414 [details] use flavors Use flavors instead of a proliferation of slave ports. Subpackages would also work in this instance.
Created attachment 248415 [details] flavors i came up with a patch that does flavours in a slightly different way, which i suppose is obsolete now, but i'll attach it for posterity :-)
Created attachment 248416 [details] use flavors Thinking I'm still at $JOB. Oops.
Created attachment 248417 [details] Flavors respecting existing package name This patch implements ldap and default flavors, whereas the default flavor maintains the same package name as existing today. It essentially adds a krb5-ldap flavor.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=9926898a0c052d79aaa08708e3249fc39e633174 commit 9926898a0c052d79aaa08708e3249fc39e633174 Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2024-02-13 00:33:16 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2024-02-13 18:47:53 +0000 security/krb5*: Flavorize with default and ldap flavors This provides a binary package to users who require MIT KRB5 with LDAP support. This patch does not change the current, now default, package name. PR: 277015 security/krb5-119/Makefile | 11 ++++++++++- security/krb5-120/Makefile | 11 ++++++++++- security/krb5-121/Makefile | 11 ++++++++++- security/krb5-devel/Makefile | 8 +++++++- security/krb5/Makefile | 2 ++ 5 files changed, 39 insertions(+), 4 deletions(-)
Fixed.
FYI, I'm not sure this is related, but today I'm getting a cyclic dependency which I can't track down yet. I'm trying to build this on FreeBSD 14.0. These packages depend on each other: * krb5-1.21.2_3 * openldap26-client-2.6.7 * cyrus-sasl-gssapi-2.1.28 The above come from: * security/krb5 (depends on openldap26-client) * net/openldap26-client (depends on security/cyrus-sasl2) * security/cyrus-sasl2
(In reply to Dan Langille from comment #10) You cannot add LDAP support to krb5 while openldap26-client depends on gssapi. You must remove either krb5 LDAP dependency or remove openldap26-client dependency on gssapi. However you can build and install the krb5 LDAP flavour. I don't know if installing it will force the removal of depending packages. Your only solution is to build krb5 without LDAP support. Then after installing openldap with the krb5 dependency, rebuild and deinstall/install the krb5 port with LDAP support by hand. This is a kludge. As a ports developer, you already know that there is no solution to circular dependencies.
Just before your reply, I found that net_openldap26-client_UNSET+=GSSAPI allowed security/cyrus-sasl2-gssapi to build. My original comment should have referred to security/cyrus-sasl2-gssapi, not security/cyrus-sasl2. Thank you for your reply.