#36781: cyrus-sasl2: use Heimdal instead of MIT Kerberos on Lion and later --------------------------+-------------------------------- Reporter: aronnax@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: haspatch Port: cyrus-sasl2 | --------------------------+-------------------------------- Comment (by ryandesign@…): Replying to [comment:2 aronnax@…]:
* nds2-client: I maintain this port, and its developers say that cyrus- sasl2 is preferred over the kerberos5 gssapi library. So nds2-client does not need a direct dependency on kerberos5 or cyrus-sasl2.
Ports that install programs that link with a library need a library dependency on the port that provides that library. Most of the programs and libraries installed by the nds2-client port do link with libgssapi_krb5.2.2.dylib so they do require a library dependency on kerberos5 (or heimdal, if that would also work).
* yafc: has a heimdal variant, and it is enabled by default
There's no particular need to change heimdal's prefix and make it conflict with kerberos5, is there? That would seem to be a step backwards.
Leaving heimdal in an alternative prefix would not represent a complete solution. The problem is that ${prefix}/bin/kinit is currently always provided by the kerberos5 port (MIT Kerberos). As a result, when a MacPorts user runs kinit, the tickets created by it are not compatible with Apple's own key store on Lion and Mountain Lion.
If we let heimdal use the main MacPorts installation prefix, have it conflict with kerberos5, and have ports that need Kerberos support use kerberos5 on pre-Lion systems and heimdal on post-Lion systems, then MacPorts applications should work with Apple's key store on all systems.
There are two courses of action that would work: 1. Do as you suggested initially, and require kerberos5 on Snow Leopard and earlier and heimdal on Lion and later. Modify all ports that use kerberos5 or heimdal to abide by this edict. Do not offer any variants to select the kerberos implementation. If it is desirable to make the kerberos5 and heimdal ports conflicting, then that would be fine. The kerberos5 and heimdal ports could even be modified so that they refuse to install on OS X versions not designed for their use. But since many users of Lion and Mountain Lion do have kerberos5 installed today, and probably some users of Snow Leopard and earlier have heimdal installed, there must be a seamless upgrade path that will result in the old port being deactivated and the new port activated (the "deactivate hack" that we've used in some other ports). 2. Allow the user to select which kerberos implementation they want. Offer variants wherever possible. The ports may not be made to conflict in this case. -- Ticket URL: <https://trac.macports.org/ticket/36781#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS