Created attachment 167428 [details] Add MIT and Heimdal from ports racoon2 will not build kink with MIT kerberos quickly tested with base heimdal and ports MIT kerberos, not ports Heimdal.
Thanks for the patch. The patch fails to build if racoon pre-exists in $LOCALBASE. It uses ${LOCALBASE}/lib over its own libraries. (Using MIT in $LOCALBASE.)
Created attachment 167590 [details] Patch to security/racoon2 to allow selection of kerberos dependency. I just cobbled this up and haven't tested it. Do you want to give this patch a try?
Created attachment 167625 [details] Improved patch. Improved patch.
I haven't had a chance to try the patch yet (that being said, visually it looks equivalent). 3 questions. 1) does the new patch address the issue of not building if it is already installed? 2) Not familiar with the new pattern for the krb5 meta-ish port (or the cfengine one for that matter), but it seems dirty to have this port depend specifically on versions of the KRB5 library. Should it not instead depend on the krb5 port and then the KRB5_VERSION such that everything in the system is tied together with that? 3) specifying --disable-kinkd and then adding --enable-kinkd also feels a bit weird (even if functional), since we have the KINK make variable, perhaps have a .if ... CONFIGURE_ARGS+= --enable-kinkd .else CONFIGURE_ARGS+= --disable-kinkd .endif ? (though certainly better then the current behavior where it could stealthily enable itself. I should have time to test this tonight, I am redoing my kerberos infrastructure with the 1.14.1 you just updated last night (thanks BTW)
(In reply to david from comment #4) 1. The patch does address building while a previous or same version is installed. 2. The meta ports are there to support those who use previous versions. For example a very large educational institution used (probably still uses) krb5-112 because of incompatibilities with their current infrastructure. Additionally a site may support their own poudriere server, using a specific version of krb5 (cfengine, etc.) when building and maintaining their own package repository (e.g. PCBSD). 3. The reason to specify --disable-kink only to enable it later is to simplify the logic, especially when multiple kerberos options (multiple MIT and two Heimdal options) must be processed. Alternatively one could avoid this by using an if-then-else construct later on in the Makefile however the logic would not be as straight forward. Additionally, the logic is simplified when updating the port when adding support for new releases of MIT KRB5 or removing support for MIT releases that are no longer supported.
My question #2 was specifically about the port itself requesting a specific port version dependency vs. depending on the new krb5 metaport and having that (via KRB5_VERSION) select the dependency going forward; having the individual ports specify their own version locks via saved options is going to cause a lot pain whenever krb5-115 comes out going through and making sure all of the options for everything is updated correctly (unless I am missing something here)
(In reply to david from comment #6) By default there is no kerberos (MIT or otherwise) prereq. It is up to the individual to select the prereq. For those maintaining their own poudriere repo, this makes sense as you may choose to use one version over the other. Unlike ports, which can be hacked or install one port instead of another, packages have specific prerequisites and installing one instead of another will only result in the uninstallation of a desired package when dependencies are satisfied. If having the latest krb5 concerns you, just install krb5. Regarding maintenance of the svn tree, we're used to this kind of stuff. Those cleaning out expired ports usually don't work with them so, they need to be careful.
Ok, just tried building it; I see what you did to resolve #1 (not building if its already installed). As-is without further patching it needs CPPFLAGS and LDFLAGS in order for kinkd ./configure to locate the kerb5 libraries and include files in /usr/local/*; without those it doesn't build at all for me, for others it probably builds, but against the version in base.
Ok, noticed a couple of additional things: 1) pre-existing issue: pkg-plist line 47 (the @exec line): %%PFX%%/pskgen as the last command in that, should be %%PFX%%/sbin/pskgen its been failing (almost) silently. Adding that still doesn't fix it however: /usr/local/sbin/pskgen -r -o /usr/local/etc/racoon2/spmd.pwd syntax error at /usr/local/sbin/pskgen line 67, near "do Getopts(" Execution of /usr/local/sbin/pskgen aborted due to compilation errors. I don't know nearly enough perl to dig through this 2) It appears that PLIST_SUBR+= KINK="@comment " takes precedence over the KRB5_PLIST_SUB= KINK="" With PLIST_SUBR defined as above kink does not get installed, removing it allows KINK to be installed.
I can't reproduce your linking issue locally. Can you send me a pkg info -aI and pkg info -ao please. Also send ldconfig -r and uname -a output. Just send it to my freebsd.org account. The perl issue: It's not detecting the correct version of perl. I'll have to look at the PLIST_SUBR issue. I don't have a naswer now.
Sorry, I was sick and out of it for a few days, trying to get back on this now.
A commit references this bug: Author: cy Date: Fri Apr 15 14:28:44 UTC 2016 New revision: 413348 URL: https://svnweb.freebsd.org/changeset/ports/413348 Log: Support the various forms of Kerberos via options. PR: 207507 Changes: head/security/racoon2/Makefile head/security/racoon2/pkg-plist
Fixed.