Slashdot Mirror
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!?)'."
"It just works"
Is this even English?
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.
-- Ed Avis ed@membled.com
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?
In Soviet Washington the swamp drains you.
I refuse to use both Fink and MacPorts because they insist on bringing in huge amounts of other stuff whenever I try to install anything. I'll build for myself from source first.
Disinfect the GNU General Public Virus!
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
Same here. I don't understand why I need the X11 sources compiled from fink just to get apache 2 and php.
Developers: We can use your help.
I use OS X server because I am a Mac-booster and because my associates and I are familiar with *nix conventions and the open-source services that generally run on them. I'd much rather deal with this than run a Windows Server platform.
And for the love of the Gods, don't try to sell me on fink and darwinports. Some people seem to think that dports putting everything it installs in a separate directory is a good thing. It's just confusing and messy.
I've tried fink and dports several times and they've never worked correctly for various reasons. If I can download and gcc compile a project's source in a reasonable amount of time, why would I bother wrestling with fink and dports?
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.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
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?
It's easy enough to install an up-to-date Perl in another location and use it instead of updating the Apple-placed Perl files and relying on them never changing.
Disk space is cheap. If it might change, don't rely on it not changing.
Yes, any OS vendor might have such problems. Why Apple is treated specially here is because:
1. The fanbois jump up and down all the time crying out "Apple is teh best" and "it just works" so loud they they shit in their pants.
2. The same fanbois will murder Microsoft if this happened to them.
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...
"Why do you bring that ancient version back, Apple!?"
You fail to grasp the essence of the situation. It is not your copy of OSX, it belongs to Apple. You did not buy it. You merely paid some money, and got a license to use it. Well, the same thing is true of the hardware - has to be in fact, because of course OSX and its hardware are seamlessly connected and integrated.
So, what went wrong was that you did not get your copy of Perl from the app store. Your copy of Perl was not approved for use with the new version of OSX. This is your fault, not Apple's. You should have checked and got permission before you installed it. It is not like you were installing it on your own property, after all. If you go and plant a cabbage in someone else's garden without permission, don't be surprised if they spray it with weedkiller.
Its exactly the same thing. Its completely weird how many people think they somehow bought a copy of the software, or bought a computer, and now they for some reason think they have the right to install whatever they want on it, and Apple has to somehow protect whatever silly thing they did to it.
Idiots! Next thing, they will be wanting to buy retail copies of OSX and install them on hardware made by any Tom Dick or Harry.
Would you say the same thing about, say, Debian's apt-get and friends?
No, because they are done correctly.
if CPAN is to be likened to apt, then it's like using Debian Experimental all the time with no option to switch to Unstable, Testing or Stable - or to switch to a particular numbered release and stay there, only getting bugfixes.
It's latest bleeding mess or nothing.
Advanced users are users too!
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.
"Microsoft killed my company, I hold a personal grudge. I don't use Microsoft products and neither should you."-JWZ
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
Michael J. Ryan - tracker1.info
How the fuck does this get modded up? You can't even fucking define a 'scripting' language you ignorant fuck. Should I start bringing up C interpreters?
More to the point, the term "DLL hell" was caused ENTIRELY BY compiled C applications. This was the ORIGINAL example of this sort of dependency problems.
How the fuck is an application missing a dependency "more brittle" depending on the language its written in? If I compiled the Perl to C, would that suddenly make it less brittle? If your C application is missing dependencies, does it magically track them down and then install them?
As for "debug and defend", an error message that says "Exiting because I can't find this dependency" is pretty fucking clear no matter the language.
That doesn't really matter as much as how Sims 2 is using Quicktime. If they are sticking to the published API and an update broke the game, then, yeah, Apple screwed up. But if they are using an undocumented macro, function, or method, then Apple isn't at fault.
FWIW, I have a few apps written against QTKit that have worked unmodified for some time now. So at least some of the API is stable. Who knows what arcane corners Aspyr is delving into, though?
Arr! The laws of physics be a harsh mistress!