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!?)'."

Scripting Languages not good for most applications

[MrData]

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.

Re:Super bad for Servers

[tbuddy23]

If you don't look at every file or at least the general path of what you are installing then you deserve it. Fink, SuspiciousPackage and the like all are very good for this.
If you need excessive amounts of PERL modules why aren't you using a generic *NIX server rather than OS X Server? The only compelling reasons I could use for using OS X Server is 1) Provide excellent AFP file services 2) You really love Mac OS X and want the whole barrage of services in the form of one mediocre server. I think Windows has an offering like that coming out soon in the form of Window Small Business Server 2008.

Re:Super bad for Servers

[ducomputergeek]

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.

Re:Fighting over the same file

[morgan_greywolf]

Some shops (mainly design studios, video studios, sound studios, etc., aside from the education market), use Macs almost exclusively and if you're going for a single-vendor solution to improve stability, supportability, etc., then that's why you'd want OS X on your server.

Personally, I think single-vendor solutions tend to trade a lack of flexibility, functionality and performance to get that stability, hence, I tend to favor 'best-of-breed' approaches, but to each his own.

Re:Use CPAN? You deserve to lose

[fl!ptop]

CPAN is the closest thing to DLL hell on Unix systems

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.

Re: OS X and package management

[SuperIceBoy]

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.

Re:Apple

[ThePhilips]

It's unfortunate that the package was broken, though compiling your own version will not void any service contracts.

They can't void service contract.

Disclaimer: I never used RHEL, only talked in past on several occasions with frustrated users. (Frustration mainly coming from the fact that they expected more freedom from RHEL, yet in the end got pretty much the same deal (albeit cheaper) as from proprietary *nix vendors.)

I was under impression that if RH support finds some custom build application, they would first ask to remove it (or restore system from backup) before they would start actually helping your with problem. At least I know of one such case with custom build Apache server.

Re: OS X and package management

[abigor]

You've got it backwards - Gentoo's system is ports-inspired, as they freely acknowledge. MacPorts is more or less the BSD ports system running on OS X.

You can set environment variables like so:

default_variants +ssl -X11 ...and so forth.

Re:Use CPAN? You deserve to lose

[mabinogi]

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.

Re:Apple

[moof1138]

not for Perl.

It's not cheap but you can get support for Perl:

http://www.apple.com/support/products/macosxserver_sw_supt.html [apple.com]

I've asked them Perl questions and they've always worked on the questions me (and gotten me a good answer).