Re: [MacPorts] #36781: cyrus-sasl2: use Heimdal instead of MIT Kerberos on Lion and later

29 Oct 2012

      #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@…):

 Note that wireshark and wireshark-devel are now among the ports that
 depend on kerberos5.

 Replying to [comment:4 aronnax@…]:
...
Replying to [comment:3 ryandesign@…]:
...
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?
I was thinking something like the following pseudocode:

 Port kerberos5:

 {{{
 platform darwin {
   if os.major is 10 or earlier {
     pre-activate {
       if heimdal is installed and active {
         deactivate heimdal
       }
     }
   } else {
     pre-fetch {
       tell the user to install heimdal instead
     }
   }
 }
 }}}

 Port heimdal:

 {{{
 platform darwin {
   if os.major is 11 or later {
     pre-activate {
       if kerberos5 is installed and active {
         deactivate kerberos5
       }
     }
   } else {
     pre-fetch {
       tell the user to install kerberos5 instead
     }
   }
 }
 }}}
...
...
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'?
Maybe. I was also thinking about whether there should be a metaport which
 just installs ${prefix}/bin/kinit as a symlink to either heimdal's or
 kerberos5's kinit, depending on the OS version.

 It would be nice if that metaport could install symlinks to all the
 relevant libraries and headers, every port that needs kerberos could just
 depend on that metaport and be done with it, but I fear it won't be that
 easy; for example yafc applies different patches depending on the kerberos
 implementation.

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