On Aug 21, 2009, at 10:54 AM, Trevor Jacques <[email protected]> wrote:
>> It installs a current perl outside of Apples perl. > > I'm not keen to do this on my OS X Server. Does your installer take > account of Apple's OS X Server set up? Can you elaborate on what your concerns are? If you were to install apache2 outside OS X server, things get strange. It can be trying, since most need better than the piss poor php it comes with. With ASSP, there is nothing OS X server has any interaction with. By putting in a new perl, I have never had an issue, and I run software update knowing when I open server admin tools, things will be just how I left them. > FWIW, I've had problems with Apple with, ahem, 'non-standard' > installations. So, I just want to keep Apple's perl and update it with > cpan where necessary, to be safe wrt Apple. But isn't that the crux of the problem? Apples perl is unarguably out of date by some degree. You add cpan modules into apples perl, software update comes along and at least has opportunity to mess with them. Even if you tell cpan to use something like /usr/local there have been 1 or 2 times Apples stomped on that area in the past as well. What the method I am using does, is instal perl in /opt. Perl modules too. ASSP is started with a full path to perl /opt/local/bin/perl assp.pl There is no chance that ASSP is running with anything outside of /opt. If you don't like it, rm -rf /opt and you are 100% back where you were. You may have to dig out a launchd item, since those have to be in Apples path. I take this as far as installing all software in /opt. I don't want Apples rsync, so I build it in /opt. On a side note, MacPorts is maintained by Mac OS Forge. They are hosted at Apple, and often I find @apple.com people on their mailing lists. Not a 100% mature project, but hands down the best package manager I have used on OS X. Hands down the most amazing support, they have helped me debug some of these SSL/TLS issues. > >> This all very well could be related in part to Apples perl. > > Until it's proven one way or another, we will never know.... It's very hard to tell. Too many variables, too many perl chained dependencies. A custom test suite for ASSP that checks all perl modules would help this go a long way. I barely know perl well enough to even consider this idea. But right now, it's far too random to troubleshoot in any meaningful way. -- Scott Iphone says hello. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
