Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Perl Programming Businesses Apple

Apple's Mac OS X Update Breaks Perl 264

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 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!?)'."
This discussion has been archived. No new comments can be posted.

Apple's Mac OS X Update Breaks Perl

Comments Filter:
  • by MrData ( 130916 ) on Wednesday February 18, 2009 @11:55AM (#26902533)
    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.
  • by tbuddy23 ( 1178415 ) on Wednesday February 18, 2009 @12:13PM (#26902775)
    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.
  • by ducomputergeek ( 595742 ) on Wednesday February 18, 2009 @12:14PM (#26902789)

    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.

  • by morgan_greywolf ( 835522 ) on Wednesday February 18, 2009 @12:18PM (#26902837) Homepage Journal

    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.

  • by fl!ptop ( 902193 ) on Wednesday February 18, 2009 @12:22PM (#26902879) Journal

    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 script, and install that instead. and never, ever install anything that's a Bundle::somepackage. build all the dependent packages by hand using 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.

  • by SuperIceBoy ( 787273 ) on Wednesday February 18, 2009 @12:29PM (#26902973)

    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 (Score:3, Interesting)

    by ThePhilips ( 752041 ) on Wednesday February 18, 2009 @02:04PM (#26904253) Homepage Journal

    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.

  • by abigor ( 540274 ) on Wednesday February 18, 2009 @03:37PM (#26905727)

    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.

  • by mabinogi ( 74033 ) on Wednesday February 18, 2009 @04:02PM (#26906173) Homepage

    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 (Score:3, Interesting)

    by moof1138 ( 215921 ) on Thursday February 19, 2009 @10:47AM (#26916331)

    not for Perl.

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

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

"Conversion, fastidious Goddess, loves blood better than brick, and feasts most subtly on the human will." -- Virginia Woolf, "Mrs. Dalloway"