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!?)'."
We don't exactly have "package managers" in OS X. The BSD side of OS X is only barely "maintained" at all, and then in some truly obscure and incoherent bubble-headed Cupertino fashion. Anything you really want to actually work with, you have to maintain yourself: PHP, Apache, rsync, ffmpeg, Perl -- all the seriously useful stuff like that you put into /usr/local and set your $PATH accordingly. You _cannot_ trust Apple not to break things.
Doh.
It's an XS module: They include components that are written in a language other than Perl, and have to be compiled against perl.
Which means that if the perl binary they are pointing to changes, they break. The code itself is fine: You just need to recompile.
Apple helpfully recompiled all the ones they shipped, so they would work. The only problem is for people who updated the modules that Apple shipped: They now have a miss-match between the Perl code that is running (that they updated) and the code that is compiled (that Apple shipped).
Basically, you've got a library header and the library object. If the header and the object don't match exactly, you've got problems. No interface was changed, no major important pieces were changed, but now you've got 1.23 headers and a 1.22 object. Change one or the other, and everything will be fine again.
As an XServe administrator, Apple's cryptic security updates are really starting to get on my nerves.
You would expect that, since it is based on multiple open-source projects that are freely available, Apple would push compiled updates through Software Update to its OS X Server users. Instead, they wait so long to patch things (like Amavis or the BIND patch for Dan Kaminsky's DNS bug) that I just get frustrated and apply the patch myself. Then, when a Apple Software Update does come down the pipe, I have to consider if installing it will break my configuration and land me in hot water with my boss when he can't get his e-mail anymore.
Apple needs to decide if they're going to regularly and consistently update the open-source software that their Server OS runs. If not, leave it alone and let the users apply and configure updates. This wishy-washy, middle-ground, Jobsy-come-lately approach is just an annoyance and an inconvenience.
This is a classic problem with most *nix distribution packages and CPAN usage. This is not Apple specific.
With MacPorts you can provide a keyword before installing to see what options an install might have.
So for instance, for apache2 you might type:
port install apache2
to install. Before doing this, try:
port variants apache2
This should produce a list. Hopefully X11 is in there (I can't verify right now). Anyway, find any options you want to enable or disable, and reform your install to look like this:
port install apache2 +enable_option -disable_option
This will usually let you strip away a goofy dep like X11 from programs that don't really need it.
For the last time, PIN Number and ATM Machine are redundancies!