#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 aronnax@…): Replying to [comment:3 ryandesign@…]:
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).
I was reading about how to do that by looking at r95305 as an example. In this case, would the deactivate hack have to be applied to kerberos5 and heimdal, or to the ports that depend on them? On what test would the registry_deactivate_composite be conditioned?
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.
In option 2, is there a way to have ${prefix}/bin/kinit map to heimdal's kinit or kerberos5's kinit at the user's discretion? Is this within the scope of 'port select'? -- Ticket URL: <https://trac.macports.org/ticket/36781#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS