Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Apple says sorry for Mac Perl breakage

by andye (Curate)
on Mar 24, 2009 at 11:49 UTC ( #752835=perlnews: print w/ replies, xml ) Need Help??

Comment on Apple says sorry for Mac Perl breakage
Re: Apple says sorry for Mac Perl breakage
by zentara (Archbishop) on Mar 24, 2009 at 12:13 UTC
    Hey ++, that shows that Perl has some respect. I guess they didn't know who to ask beforehand, to test for compatibility.

    Sounds like a nice part-time consulting job for an enterprising Mac-savvy monk.

    To return the favor, I would like to dual boot a Mac laptop with a linux distro. Mac equipment is what Microsoft SHOULD have been. It's high quaility and runs something similar to linux. :-)


    I'm not really a human, but I play one on earth My Petition to the Great Cosmic Conciousness
Re: Apple says sorry for Mac Perl breakage
by MidLifeXis (Prior) on Mar 24, 2009 at 13:42 UTC

    Did I read this correctly, that if you installed your own version of Perl, all is still well with the world?

    This would be yet another argument to install your own version of perl, and not rely upon the OS version for your application.

    --MidLifeXis

    The tomes, scrolls etc are dusty because they reside in a dusty old house, not because they're unused. --hangon in this post

Re: Apple says sorry for Mac Perl breakage (sort @INC)
by tye (Cardinal) on Mar 25, 2009 at 07:41 UTC

    "Apple's Moy says the problem is due to the way Perl orders its module directory search path"

    A while back I was a bit shocked to find out how badly the order of directory searching was broken in Perl because it seemed pretty obvious to me that user-specific directories should be searched before site-specific directories before "came with the distribution" directories (and that this is especially true for the easy-to-predict scenario of installing a new version of a "core" module). (I even read a thread at PerlMonks this week where this search-order breakage was implicated.)

    I got pointed to some vague references to how "it has to be that way, for now" but could never find or get an explanation of how it got broken (I recall, in the long-distant past of doing porting, perhaps even for Perl 4, that this obvious case was properly handled, though I might be misremembering that) and what depends on that breakage.

    I'd love to hear or be pointed to some background on that.

    - tye        

      Just meditating, but to me it makes perfect sense to me that the directory search path comes in this order, especially when it comes to core. I think it follows a philosophy of 'adding on' modules, not 'enhancing existing' modules with over-rides. I think the distribution directories should contain nothing but core, tested and proven to work in harmony with the rest of the OS and attempting to upgrade them should not be taken lightly with a simple user search path over-ride. From an application point of view we're quite comfortable with over-riding just about anything in Perl, but from an OS point of view, I don't think you want that to happen (easily anyway).

      What shocks me is that the core modules that Apple broke where 'upgraded' by users because the the Apple versions were old and out of date. The finger pointing at search path order seems to have overshadowed the fact that Apple has neglected to keep it's Perl core up to date.

        You make a good point about not using the user's module updates for the system tools. However, the system tools should normally be run as a superuser account, which shouldn't normally be used for day-to-day production programming.

        Beyond that, even system-wide system-specific module upgrades shouldn't change anything for OS distro utilities that use the modules. If they're packaging perl, the Perl modules, and packaging the apps that depend upon those modules, then the packagers of those dependent apps should have no problem knowing and using the exact paths to the original versions. There's even an optional vendor_perl directory one can configure during the perl build that's just like the site_perl directory. Mandriva uses it, so why not Apple?

        I can understand the hesitation for a company that sells products based on "it just works" to bundle the latest and greatest software in their distribution all the time. I'm sure they only use things they're had time to test as units and in integration. While being on the cutting edge is great for some, when you're selling boxes to lots of people and want few support issues, you usually do stay back a few releases for stability and testing reasons.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlnews [id://752835]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (5)
As of 2014-12-19 06:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (71 votes), past polls