Apple's Mac OS X Update Breaks Perl
mir writes "It looks like if you use CPAN to install modules, Apple's latest security update might just have broken your Perl. According to Tatsuhiko Miyagawa 'The Security Update brings (old) IO.bundle with version 1.22 but your IO.pm has been updated to the latest 1.23 on CPAN shell. (But hey, 1.23 was released in 2006...Why do you bring that ancient version back, Apple!?)'."
In the flamebait but true category, this is further evidence why scripting languages are not suitable for most application development ... because they are much more brittle than a traditionally compiled application.
True you can site examples of traditionally compiled applications breaking due to missing dependencies, in which (like with this Perl example) the underlying deployment platform is a fault, but this type of problem is much more common with scripting languages (Perl, PHP, Python, etc), and vastly harder to debug and defend against.
I love Apple laptops and desktops. Hate Xserve and I've found OSX-Server to be nothing to write home about. When I was an Apple Certified consultant, I saw a much higher than average failure rate with Xserve hardware. It got to the point to where we'd only deploy OSX-server on PowerMac/MacPro machines. I know some people love their OSX-server tools admin package. It is a pretty slick GUI. I will give them that. But really, I can do just about anything OSX-Server can on a default OSX install. And for the price, I can build reliable servers with FreeBSD a lot cheaper with the same functionality, and arugably even more functionality than OSX-Server.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
while i prefer centos for my production systems and don't use osx, i recommend implementing a solution i've found to work well. first, disable any rpmforge repos on your production machine. second, install new cpan stuff on your development server. test, then install on the production machine (if it passes the tests).
if you need a cpan module that's not available from the regular repositories, or from rpmforge, *never* install anything from cpan using make, make all, etc. always make an rpm using the makerpm.pl script, and install that instead. and never, ever install anything that's a Bundle::somepackage. build all the dependent packages by hand using makerpm.pl instead.
i've found that these methods help cool the 'dll hell' on my production machine. i rarely have any problems. i can't comment on how well this would work w/ a debian-based system that doesn't use rpm, however. not sure what kind of package management osx uses, either.
When you recognize love in another and realize how precious it is, everything else seems so insignificant.
Same here. I don't understand why I need the X11 sources compiled from fink just to get apache 2 and php.
Not sure about on Mac, but on FreeBSD I define WITHOUT_X11 so that it doesn't do that.
CPAN _was_ an excellent thing - in 1997.
Now, the GP is exactly right - it's a mess.
You absolutely need to install the latest perl before you use it - because the perl (or the modules installed with it) installed with your OS is always too old for any particular module you want to install, and even then you have a chance that the module you want is either broken, or depends on a currently broken module.
CPAN is the heart of perl, but that doesn't mean it's perfect. It seriously needs fixing.
Advanced users are users too!