Apple's Mac OS X Update Breaks Perl 264
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!?)'."
Apple (Score:3, Insightful)
"It just works"
WTF (Score:0, Insightful)
Fighting over the same file (Score:5, Insightful)
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.
Why does this "break" anything? (Score:5, Insightful)
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:Fighting over the same file (Score:5, Insightful)
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: OS X and package management (Score:3, Insightful)
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.
Re:Use CPAN? You deserve to lose (Score:3, Insightful)
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
Re:Fighting over the same file (Score:5, Insightful)
"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: OS X and package management (Score:3, Insightful)
Same here. I don't understand why I need the X11 sources compiled from fink just to get apache 2 and php.
Re:Super bad for Servers (Score:2, Insightful)
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?
Didn't break my Perl, did break Catalyst (Score:4, Insightful)
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 (Score:4, Insightful)
Easy fix: Stop changing Apple's files. (Score:3, Insightful)
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.
Re:Fighting over the same file (Score:4, Insightful)
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.
Any OS vendor? But Apple is not ANY OS vendor (Score:0, Insightful)
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.
Re:Scripting Languages not good for most applicati (Score:4, Insightful)
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...
Apple was right to break it! (Score:3, Insightful)
"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.
Re:Use CPAN? You deserve to lose (Score:2, Insightful)
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.
Only occurred if core system was modified (Score:4, Insightful)
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 (Score:5, Insightful)
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
Re:Scripting Languages not good for most applicati (Score:1, Insightful)
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.
Re:Fighting over the same file (Score:3, Insightful)
I don't think the situations on Linux and MacOS are as similar as you're making them out to be. Every Linux distro explicitly tries to support as many CPAN modules as possible, and every Linux distro has as one of its main goals making it easy in general for users to install open-source software. These are just not high priorities for Apple. You want to use OSS on MacOS? Sure, you can try to get it from Apple, you can try to get it via Fink, you can try to get it via MacPorts, or, in the case of a perl module, you can try to get it via CPAN. It's a mess, especially considering that option #1 has very little coverage, and options #2-4 are not supported by Apple.
Sure, this type of conflict can occur on Linux, but it's much easier to avoid. Basically, whenever I need a CPAN module I check whether there's an Ubuntu package for it. 99% of the time there is, and I install it via apt. The other 1% of the time, I install it via CPAN instead. No conflicts, because there's no overlap between the two sets.
Re:Apple: Breakin' a bunch of crap recently (Score:3, Insightful)
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?
Re:Apple (Score:2, Insightful)
Hey, does anybody remember that awesome time long ago when Apple first included Python with OSX? For awhile there the version installed was Python 2.3. Not 2.3.x like the versions that actually exist and everybody else uses. Just Python 2.3. It was like a special Apple only version of Python.
My favourite feature was that it didn't pass all the tests in the test suite, like it was so special that they just knew they didn't have to test their special Apple build of Python. In particular the pickle module was hosed which maybe didn't bother all that many people but if you happened to be working on something in Python on a Mac using that build of Python all those years ago then maybe, just briefly, you sensed the reality distortion field weakening and maybe you even uttered a few harsh words about Apple under your breath.
That was the best Python ever.
And now you can use special Apple Perl. Apple is just so awesome.
Re:Fighting over the same file (Score:3, Insightful)
"On a modern Linux distribution, it's actually okay to modify stuff that the vendor sends you"
Let me fix that for you. "On Linux, there's an attitude that it's ok to modify stuff the vendor sends you."
Good luck with that.
(I'm on a Mac, and I download ported-from-linux, OS X-installer packaged stuff from time to time, and more often than not it wants to install into /usr or /usr/bin with no option to go anywhere else (asterisk comes to mind). In my world, that means it doesn't get installed. Period. Yea, maybe I'll hack it up to install into /usr/local, but I generally don't have the time or inclination to fix broken stuff)
A.