##Plan Mac Installer for GSS EAP and SASL GS2 libraries
###Introduction:
-This document describes Codethink's plan for producing an installer for the Moonshot GSS EAP and SASL GS2 libraries for Mac OS X 10.6 (“Snow Leopard”) and 10.7 (“Lion”).
-It describes the goals, activities, deliverables and milestones for the development.
-It also gives some background on the intended locations of the files to be installed, system configuration modifications and any other pertinent information. It explains how the installer conforms to Apple’s relevant guidelines to developers.
+This document describes Codethink's plan for producing an installer for the Moonshot GSS EAP and SASL GS2 libraries for Mac OS X 10.6 (“Snow Leopard”) and 10.7 (“Lion”). The installer will include the libraries and all dependencies, and will perform any configuration necessary to allow the libraries to be used.
+
+The Moonshot GSS EAP library implements the EAP mechanism for use by the GSS API. The GSS API is implemented by the Kerberos whoich ships with the OS (but see Issues below)
+
+The SASL GS2 Library implements the GS2 SASL mechanism for use by the SASL2 library.
+
+The document describes the goals, activities, deliverables and milestones for the development. It also gives some background on the intended locations of the files to be installed, system configuration modifications and any other pertinent information.
###Goals
-The primary goal is to allow users to install these initiator libraries on a computer running Mac OS X without needing to build them from source.
+The primary goal is to allow users to install the libraries on a computer running Mac OS X without needing to build them from source. Once installed, the libraries can be used to provide authentication services to programs which use them.
Secondary goals are
-1. To allow users who are familiar with the autotools tool chain to install, as well as build, the libraries using autotools on a computer running Mac OS X. (This is currently possible for the Cyrus SASL library, but not for the Moonshot GSS EAP library).
+1. To allow users who are familiar with the autotools tool chain to install, as well as build, the libraries using autotools on a computer running Mac OS X. (This is currently possible for the Cyrus SASL library and plugins, but not for the Moonshot GSS EAP library).
2. To automate (as far as possible) and document the process, allowing Moonshot project developers to easily produce installer packages for future versions of these libraries.
4. Instructions and scripts for creating the installers and disk images from source. PackageMaker, (the tool provided by Apple to build installer packages - see Ref. 2) does not have a command line interface, and there do not appear to be any freely available alternatives which do, so it will probably not be possibly to automate the production of the installer package(s).
###Activities and Milestones
-1. Build and install the Cyrus SASL Library for Mac OS using autotools to prove this currently works and that it is a valid goal for the Moonshot GSS EAP library. Due Wednesday 16th November.
+1. Build and install the Cyrus SASL GS2 Library for Mac OS using autotools to prove this currently works and that it is a valid goal for the Moonshot GSS EAP library. Due Wednesday 16th November.
2. Create an installer package and compressed disk image for the Cyrus SASL Library, with notes on how to achieve the process. Due Friday 18th November.
3. Make the necessary changes to the Moonshot GSS EAP library source and configuration files to build and install it for Mac OS using autotools. Due Friday 25th November.
4. Create an installer package and compressed disk image for the Moonshot GSS EAP library. Due Tuesday 29th November.
5. Create the scripts and instructions. Due Wednesday 30th November.
###Issues and questions
-####To be resolved ASAP
-Q: Luke> What's the actual framework binary (that is, /Library/Frameworks/Moonshot.framework/Moonshot) going to link to -- libmoonshot-ui? That would make the most sense as mech_eap and the GS2 SASL plugin aren't directly linked against by applications. By convention, you'll need to have something there (otherwise it's not really a framework).
-> A: Pete> I was planning to link /Moonshot.framework/Moonshot to the mech_eap dynamic library. libmoonshot-ui (or whatever replaces it in the refactored Identity Selector software) will be created and installed when we port the Identity Selector to Mac OS, which is a separate task. As I understand it, mech_eap *is* the Moonshot GSS EAP library. If it isn't directly linked against by applications, do we just install it in /usr/local/lib and forget about creating a framework? I still need to get to the bottom of this issue, before I start making the installer for it.
-
-Q: Pete> New issue - do we need to do the versioning as suggested in the plan, or can we just overwrite the existing installation?
####To be resolved during implementation
Q: Sam> One of the big questions will be to what extent will you use system dependencies and to what extent will you package your own. You'll want to look over the build instructions Josh pointed you at. If you're packaging the acceptor, then all of the dependencies on the preparation page as well as everything built by the builder script apply.If you're packaging an initiator, you need Kerberos and not much else.
> A: Pete> My inclination for the Mac installer is as far as possible to use what ships with the OS - in this case Heimdal for Lion - but to include anything else in our installer - even if it *may* already be installed to support another program.
Q: Pete> Which files in which directories?
####Resolved Issues (I think)
+Q: Luke> What's the actual framework binary (that is, /Library/Frameworks/Moonshot.framework/Moonshot) going to link to -- libmoonshot-ui? That would make the most sense as mech_eap and the GS2 SASL plugin aren't directly linked against by applications. By convention, you'll need to have something there (otherwise it's not really a framework).
+> A: Pete> I was wrong - Moonshot GSS EAP is not a framework, and we won't create /Library/Frameworks/Moonshot.framework. Instead the libary will be installed to ????
+
+Q: Pete> New issue - do we need to do the versioning as suggested in the plan, or can we just overwrite the existing installation?
+>A: Pete> The library isn';t a framework and is not linked to directly by apps, so we don't need versioning.
+
Q: Sam> What prevents moonshot gss eap from being built using autotools today? It's my understanding that Luke does this regularly.
Q: Luke> As Sam said, I'm not exactly sure what you meant about building with autotools. Were you talking about building with the autotools that ship with OS X? (That may not be possible.) Or a script that invokes autoconf with the appropriate arguments to install in the Mac filesystem hierarchy? Because I do all my development on OS X and I haven't had any problems with autotools and Moonshot (no more than one might usually have).
1: The installer will install library and header files in /usr/local/lib and /usr/local/include, as for the Linux 'make install'.
-2: Frameworks: in addition, the installer will install frameworks in sub-directories of /Library/Frameworks on the main drive of the machine. The Cyrus SASL framework will be installed in /Library/Frameworks/SASL2.framework (as in the existing Cyrus SASL 'make install'). The Moonshot GSS EAP framework will be installed in /Library/Frameworks/MoonshotGSS_EAP.framework. The installer will create the .framework directories if they are not already present. The frameworks are wrappers for symlinks to the respective dynamic libraries in /usr/local/lib (libsasl2.dylib and mech_eap.dylib).
+2: SASL2 Framework: in addition, the installer will install Cyrus SASL framework will be installed in /Library/Frameworks/SASL2.framework (as in the existing Cyrus SASL 'make install' and as recommended by Apple's guidelines to developers). The Moonshot GSS EAP framework will be installed in /Library/Frameworks/MoonshotGSS_EAP.framework. The installer will create the .framework directories if they are not already present. The frameworks are wrappers for symlinks to the respective dynamic libraries in /usr/local/lib (libsasl2.dylib and mech_eap.dylib).
If an installation with a lower version number is present, the new installation will be installed, and the /Versions/Current alias changed to refer to the new installation.
The appearance of the installer will not be customized to use special icons and window backgrounds.
-Apple's Developer documentation (Ref. 1) states
-> public frameworks should be installed at the local level in /Library/Frameworks.
-Frameworks installed here are available to all users of the machine.
-
-####Structure of the Moonshot.framework directory tree.
-The Moonshot.framework directory will have the following sub-directory structure, allowing future versions to be installed without breaking applications that rely on an earlier version:
-
- /Headers -> (alias to Versions/Current/include)
- /Home -> (alias to Versions/Current)
- /Libraries -> (alias to Versions/Current/lib)
- /Versions
- /1.0.1
- /1.0.2
- ...
- /3.1.2
- /Current --> (alias to most recently installed version e.g /Versions/3.1.2)
-Each numbered version sub-directory will have the necessary directories from the file system hierarchy e.g.
-
- /etc
- /include
- /man
- /etc
- /lib
- /sbin
- /share
- /doc
- /xml
- /var
- /log
-
###Package and Component Properties
The Package properties will be
projects / devwiki.git / commitdiff