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

Comments

Apple

[Anonymous Coward]

"It just works"

Fighting over the same file

[Ed Avis]

Why are Apple's updater and Perl's CPAN shell both trying to update the same file? If the file's there as part of the Apple OS then only the OS's package manager should touch it, and Perl should leave it alone (installing its own version in /usr/local if necessary). It's exactly the same on Linux distributions: the CPAN shell doesn't try to mess with the system perl which is updated using rpm or dpkg.

Re:Fighting over the same file

[99BottlesOfBeerInMyF]

We don't exactly have "package managers" in OS X.

Sure we do, a bunch of them. That's kind of the problem.

Anything you really want to actually work with, you have to maintain yourself

That's a bit of an overstatement. Anything you want a cutting edge version of you'd do well to install and maintain yourself outside of Apple's update path, but for most people just using the Apple installed versions is fine.

Re:Fighting over the same file

[Alrescha]

"Why are Apple's updater and Perl's CPAN shell both trying to update the same file? If the file's there as part of the Apple OS then only the OS's package manager should touch it, and Perl should leave it alone (installing its own version in /usr/local if necessary)."

Why must we learn these lessons again and again? Back in the beginning of time (1983), we learned the following:

Rule #1: Never change *anything* that [vendor] sends you

Rule #2: Always keep your stuff separate from [vendor]

(thank you Melinda)

Re:Fighting over the same file

[Ed Avis]

On a modern Linux distribution, it's actually okay to modify stuff that the vendor sends you, provided you do it using the same infrastructure as the vendor. For example, on an RPM-based system, you can easily build and install your own local RPM packages, with dependencies and all that, and they integrate nicely with the vendor-supplied ones. I wanted a newer version of the Perl LWP library than was in Fedora 10, so I grabbed the source RPM, updated it and built my own RPM package which I installed. Fedora then won't overwrite this unless they push out an even newer LWP release. Exactly the same can be done with dpkg-based systems.

If your vendor is incompetent, or you are paranoid and don't trust them, or some mixture of the two, then there may still be political reasons not to alter the vendor packages and instead put duplicate copies in a different directory. But nowadays there aren't always technical reasons why you shouldn't.

Why does this "break" anything?

[mi]

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

The real question is (or ought to be), why is the 1-digit difference in the minor version number break things? If the 1.22 -> 1.23 change was important (as in interface-changing or something), shouldn't the new version have been named 1.3 or even 2.0?

Re:Use CPAN? You deserve to lose

[Anonymous Coward]

This is certainly a comment by someone who doesn't understand a single piece of Perl, and how Perl developers work.

CPAN *is* Perl, if you take it out, Perl has little more value than any other modern VHLL (python, ruby etc).

The problem is that if you're going to develop a large system, you need both a development methodology and a maintainance methodology, if you don't plan those, "You deserve to lose".

In a modern environment, like Debian, you manage all your CPAN dependencies as debian packages, hopefully integrating them into the debian main archive (through the pkg-perl group). That way, it will be easier to keep them up-to-date both in Debian and obviously in your machine later, where you will be able to do just a apt-get dist-upgrade to have that done.

daniel

Didn't break my Perl, did break Catalyst

[Kostya]

The update reverted Scalar::Util, which disabled the weak reference stuff needed by a lot of Catalyst libs. I just re-installed it and it worked again.

But on all my new machines, I just use a local lib instead of the system stuff. I don't need sudo access and then the whole lib gets backed up by Time Machine. If you just upgrade the system perl, you have to re-do it every time you restore from a Time Machine backup (it doesn't copy system stuff as near as I can tell).

Also, as some have observed, CPAN is a bad idea. I say this as someone who got screwed when Catalyst went to 5.7100 (I was at 5.7015). When I did a restore to a new machine, CPAN got all the new Catalyst libs and all my customizations blew up spectacularly.

If you are doing serious Perl development on your local Mac, use a local lib and do not rely on CPAN to automatically handle your dependencies. Install things by hand or create a (perl) script to handle the deps for you. That's what we had to do, as we needed to make sure the module version we used matched our production systems--where we do NOT use CPAN and where we upgrade manually and with careful thought.

Re:Super bad for Servers

[fuzzyfuzzyfungus]

The question isn't Apple vs. Microsoft, it is Apple vs. other Unixlikes. Why run OSX server rather than Solaris, one of the BSDs, or linux?

Re:Scripting Languages not good for most applicati

[shutdown -p now]

this type of problem is much more common with scripting languages

I don't see how this follows in any way. Can you give some examples of why it would be more common for scripting languages? In this case, the compat problem is not with a Perl script, as I understand it - it's with a binary Perl extension that got linked against the wrong version of Perl library; so, really, it is rather an example of how brittle compiled stuff is...

Only occurred if core system was modified

[Killer Eye]

This problem occurred only for people who updated their system's Perl distro via CPAN.

A vendor is free to do what it wants in the part of the system it supports. This isn't new, it's been done for decades on Unix with the distinction between the /usr/local hierarchy (a.k.a. "your crap, not ours") and the rest of /usr (i.e. "our crap, not yours").

People need to know that it's better to install customizations in /usr/local/lib/perl5, or even their home directory, than to fiddle with the vendor setup. This not only avoids vendor clobbering, but the separation is cleaner: mistakes are easier to contain and undo, you can easily test whether a problem is with your customizations or the vendor defaults, you don't necessarily need admin privileges, etc.

Comparing Apple's Release Cycle to MS

[aztracker1]

That's funny... since 2000, MS has had two releases you'd have to pay to upgrade to... How many has Apple had? more than two... As for being constrained to the release cycle most new software runs in XP still... how much new Mac software runs in less than 10.3? not much.

I actually like OSX, it has a consistent UI on a Unix core. But your arguments only show your ignorance. For the record I like different aspects of a lot of OSes. There are even parts of Vista I like (mainly the restructuring of the user paths... though would rather have an "ALL" user back, opposed to the new location for global settings. I like that Linux has a FLOSS mindset, even if the zealots can't find a balance with commercial software.

I don' like a lot of the more politically minded decisions MS and others have taken. I find it ironic that Linux fanbois will use Samba, but ignore Mono because of patent concerns. Zealots from every corner are wrong, and spread FUD, it's what they do... the truth is generally somewhere in the middle.

-- happy Windows, Linux, BSD & Mac User