wot no comments
surprised there could not be some informed comments on this incidenct - either pro or con
Apple has apologized for breaking Perl with its latest Mac OS X security update, saying it will distribute a solution to the problem with a future update. In a note to The Reg and a post to the Apple support forums, Senior Apple programmer Edward Moy apologized for "the unforeseen problems that the 2009-001 security update has …
/shrugs. Know a several pearl developers who are also full time Mac users and it was a non issue for 'em. One already figured out the issue after installing the updates and couple others were to busy with projects to install the updates and so had already heard about the work arounds. Yes it was another misstep for Apple, but in the end for the majority of people it effected it was a short term annoyance at best and they were back and working in no time.
CPAN is a wonderful resource. CPAN.pm and CPANPLUS are great interfaces to it. They download set up not just the code but the tests for the code, the build mechanism, and an automated way to run the tests. They keep track of which modules you have installed and manage dependencies. That makes the CPAN interface modules a package management system.
Apple's system updater is another package manager completely independent of CPAN. It will update anything on your OS X system without concern for what other mechanisms you're using for updates.
The problems arise from using both of these on the system's perl installation ('perl' being the tool for the language 'Perl' -- people can get picky about the capitalization of the two). There are ways to have the CPAN package management modules install to places other than where your system-wide modules are. It's even possible (and not difficult) to keep a completely separate installation of perl that's updated separately from the system's perl.
Many people in the Perl programmer community recommend having a separate perl installation which can be updated without regard to the system's installation. This allows one to go through a system update without breaking your production environment. It also allows you to update your production environment without breaking parts of the OS distro that may depend on certain versions of perl with certain features or certain versions of certain modules . I've never checked how much in OS X depends on the language, and I'd guess it's not much if at all. Mandriva and some other Linux distros OTOH use a great deal of Perl in their distro-specific tools.
Good call on not using CPAN along with another package manager. The same applies if your "other" package manager is apt/dselect/aptitude or whatever fancy new util cooked up for handling .debs.
It's understandable how it happens (after you've sorted everything out!) but it's a really frustrating diversion from PERL's usual "it just works" behavior.
Now If I could just figure out how to get CPAN to uninstall something...
Mines the one with the dog eared Camel book in the inside pocket.
Apple didn't stuff the OS, those people who used CPAN on the system version of Perl did.
As noted by Christopher E. Stith above, no experienced admin would *EVER* mess with the system installed version of Perl as the vendor add-ins *WILL* break if you do. This is the same on all OS distributions, be it MacOS, Linux (or any flavour) or Sun Solaris/OpenSolaris.. or, indeed, Microsoft Services for Unix.
If you want a customised Perl (or Python, or <add your interpreted language here>) then you build your own version and customise it.
Just get my fanboi hat on here....right.
"There's nothing wrong with Apple. It works perfect all the time. You must have done something to it! There are ways to work with OSX and ways not to, you must over come your ignorance and do things "the Apple way", then they will work as intended. The system is good! The system works!"
That's better!
@Fuzzy Wotnot:
Yes, certainly. Believe what you like. Except the reaction would have been the same no matter what OS you were running. RHEL has a system-installed Perl, managed by up2date/yum. You don't go messing with that. Solaris has a system-installed Perl. It has its own patch-management system, so you don't tinker with it.
I'll stick my neck out here: If Windows came with its own system-installed Perl, you would not mess with it.
In all these cases and with OS X, you install your own Perl if you want anything nonstandard. Experienced sysadmins tend to think of system-installed Perl as being "not mine", and truly it isn't: it's there for the convenience of the OS maintainers.
By tinkering with the system-installed Perl, you don't know what you might be breaking in the OS itself.