#52431: opensc @0.16.0: add variant +tokend to install TokenD module ---------------------------------+-------------------------------- Reporter: leonardo.schenkel@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: maintainer haspatch | Port: opensc ---------------------------------+-------------------------------- I am submitting a patch that introduces a new `+tokend` variant to enable building and installing the OpenSC TokenD module that allows macOS and the Keychain to interface with the smart cards. The reason for this being a variant and not a new `opensc-tokend` port dependent on `opensc` (which would be nicer) is because OpenSC does not have a stable API/ABI so any mismatch of `libopensc` and the version the TokenD has been built against is likely to cause runtime issues — which is extra disturbing given the fact that the TokenD is a module loaded by the macOS system and could cause system-wide instability. I also asked in the `opensc-devel` mailing list about how to best build TokenD (if as a separate package or not) and I got the following two replies so far (trimmed for brevity): Frank Morgner: libopensc's API and ABI has changed in every release I have seen in the past. That's why we are building both packages together https://github.com/OpenSC/OpenSC/blob/master/.travis.yml#L66 and I don't think it makes much sense decoupling them. Additionally, I suppose users are expecting the MacPorts package(s) to be identical to the download release on Github, which also implies building tokend together with libopensc. Martin Paljak: It better be +tokend in this wording. Think of OpenSC.tokend like out-of-tree PKCS#11 or Minidriver interface of OpenSC. It could also be bundled inside OpenSC code tree as well (but is not, for historical reasons). Martin does mention that it is possible to build the TokenD as a separate package, however he still recommends the variant as a first choice. Note that building them together is exactly how upstream is built, so I replicated the way that the upstream build script works. Since nobody else seems to be building them separately, I believe it is ill-advised to separate the two into different packages which are installed separately and risk making the MacPorts package being vulnerable to API/ABI changes when nobody else is. I also took the opportunity and did some minor changes in the Portfile that don't affect the way it's built. I'm not an expert on Portfile creation, so it's possible or even likely that the way I'm building the TokenD here could be improved or simplified. I'm open to any feedback to improve this patch. -- Ticket URL: <https://trac.macports.org/ticket/52431> MacPorts <https://www.macports.org/> Ports system for the Mac operating system