[MacPorts] #34230: kerberos5 @1.10.1 port update and more

[MacPorts]

#34230: kerberos5 @1.10.1 port update and more
-----------------------------+----------------------------------------------
 Reporter:  quentin@…        |       Owner:  macports-tickets@…                   
     Type:  update           |      Status:  new                                  
 Priority:  Normal           |   Milestone:                                       
Component:  ports            |     Version:  2.0.4                                
 Keywords:  haspatch         |        Port:  kerberos5                            
-----------------------------+----------------------------------------------
 I've attached a patch here to update the kerberos5 port from 1.7.2 to
 1.10.1. In addition to the patch, {{{files/patch-
 pkinit_crypto_openssl.c.diff}}} should be removed as it's no longer
 needed.

 This new portfile also provides two new variants:

  * {{{com_err}}}, which selects whether to install kerberos5's copy of
 com_err. With this variant disabled, kerberos5 can be installed side-by-
 side with e2fsprogs. This variant defaults to on for backwards
 compatibility, but I think it should probably be turned off at some point.
  * {{{rename}}}, which installs the Kerberos binaries with an "mit-"
 prefix. This is especially important on Lion, where the system-provided
 Kerberos is not MIT Kerberos, and you often want to invoke both binaries.
 Again, for backwards compatibility with the previous port, this defaults
 to off.

 I still know of a few outstanding issues with this port (though it's still
 better than it was before):

  * It doesn't appear to link against libintl correctly; I have worked
 around this by disabling the configure check for libintl.
  * If the {{{rename}}} variant is set, it installs a set of headers and
 libraries (such as {{{gssapi.h}}} and {{{libkrb5.dylib}}} that conflict
 with the system-provided versions. This is especially important since the
 system-provided Kerberos and this port are NOT fully compatible. It's
 especially bad since other ports will compile differently depending on
 whether this port happens to be activated!

 I'm not sure how to resolve the latter point; it seems like this is a
 long-standing issue with this port. I could perhaps introduce a
 {{{devel}}} variant that installs the includes and libraries, but MacPorts
 doesn't seem to do that very often. Could this be a use case for subports?

-- 
Ticket URL: <https://trac.macports.org/ticket/34230>
MacPorts <http://www.macports.org/>
Ports system for Mac OS