+###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: Sam> One of the big questions will be whether you can use the system Kerberos. My assumption is that you cannot for 10.6. You may be able
+to do so for 10.7. This will be one of the big open questions we're expecting the plan to answer.
+> A: Pete> Googling for 'mac os X Lion Heimdal' gives a worrying number of forum posts about problems. I'm concerned that we could end up spending time debugging 'Lion's Heimdal' which is not what you are paying us for! 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. So for Lion, we should start by using Heimdal, but if we hit problems then, rather than spending a long time tracking down the problem, our first step would be to try whatever we used for Snow Leopard.
+
+> Josh> Sounds like a plan
+
+> Pete> Further information in the mailing list at https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1111&L=MOONSHOT-COMMUNITY&D=0&X=09511F3D9F0F762A88&Y=pete.fotheringham%40codethink.co.uk&P=12159 and https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1111&L=MOONSHOT-COMMUNITY&D=0&X=09511F3D9F0F762A88&Y=pete.fotheringham%40codethink.co.uk&P=13011
+
+Q: Pete> One package each for "Snow Leopard" and "Lion", or a single package that works for both? One disk image each for "Snow Leopard" and "Lion", or a single disk image containing both packages?
+
+Q: Pete> Which files in which directories?
+
+Resolved Issues (I think)
+==========
+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).
+> A: Pete> No problems that I know with *building* but I didn't think it could be *installed* in Mac OS using 'configure && make install' as can be done with the Cyrus SASL. I think that would be a useful secondary goal for this piece of work.
+
+Q: Pete> Which libraries?
+A:
+> Josh> the SASL library is self-contained within cyrus-sasl.
+
+> Sam> I think our changes have all been folded upstream at this point.
+
+> Sam> the moonshot directory contains the GSS-EAP library
+
+> Pete> so the SASL library is cyrus-sasl/libsasl2 and the GSS_EAP library is moonshot/mech_eap
+
+Q: Sam> Does their SOW involve packaging all the dependencies for an acceptor build or an initiator only build?
+> A: Josh> It might be prudent to work towards an initiator-only build, at least initially, as this significantly reduces the size of the problem. The message for Pete is to obtain sufficiently new krb5, the moonshot project from the git repo, and build an initiator from those? I'm pretty sure we don't need a Mac acceptor.
+
+Q: Luke> The framework directory should surely be Moonshot.framework, not Moonshot, if it indeed is a framework
+> A: Pete> Agreed. Document changed
+
+Q: Luke> org.janet should be net.ja (unless janet.org is registered to JANET?)
+> A: Pete> Document changed
+
+Q: Luke> Are you planning to install Cyrus SASL as a separate framework?
+>A: Pete> Yes. Installing Cyrus SASL to /Library/Frameworks/SASL2.framework (as in the existing 'make install'). I have changed the plan to reflect this
+
projects / devwiki.git / commitdiff