Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apple's Mac OS X Update Breaks Perl

CmdrTaco posted more than 5 years ago | from the how-will-i-regex-now dept.

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

cancel ×

264 comments

Sorry! There are no comments related to the filter you selected.

Yes! (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26902157)

0th!

Apple (3, Insightful)

Anonymous Coward | more than 5 years ago | (#26902163)

"It just works"

Re:Apple (5, Funny)

telchine (719345) | more than 5 years ago | (#26902273)

Some would argue that Perl has been broken for a long time before Apple started meddling!

Re:Apple (3, Informative)

ThePhilips (752041) | more than 5 years ago | (#26902653)

This is not a first Apple's blopper. Any OS vendor might have those.

The question is how long would it take for Apple to fix that. In the blog post linked Fedora Perl issues actually took about year to deliver fix for RHEL.

While compiling and using your own build of Perl (or using Fink) on Mac OS X is absolutely OK, under RHEL that might easily screw up your RH support contract...

Any OS vendor? But Apple is not ANY OS vendor (0, Insightful)

Anonymous Coward | more than 5 years ago | (#26903863)

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.

Re:Apple (5, Funny)

Gadget_Guy (627405) | more than 5 years ago | (#26902777)

Oh, I see. I was under the impression that the phrase "It just works" was a synonym for something like "It simply works". Apparently it is a synonym for "It barely works".

OK, that was a bit unfair. Every OS gets the occasional problem when doing updates. Assuming that there is a forthcoming fix in the near future, there is no need to obsess about it.

Re:Apple (2, Funny)

icannotthinkofaname (1480543) | more than 5 years ago | (#26903013)

Oh, I see. I was under the impression that the phrase "It just works" was a synonym for something like "It simply works". Apparently it is a synonym for "It barely works".

I thought "It barely works" is M$ Windows. Or is there less difference between the companies than one would initially guess?

Re:Apple (1)

hobbit (5915) | more than 5 years ago | (#26903481)

Flamebait? Get a sense of humour (and perspective).

Re:Apple (0)

Anonymous Coward | more than 5 years ago | (#26903183)

"This is another reason why you shouldn't use Perl that comes from vendors," Miyagawa says. "Apple isn't any different from Fedora on this!"

Re:Apple (1)

leamanc (961376) | more than 5 years ago | (#26903223)

It does just work, if you take what Apple gives you and don't customize it too much. Installing your own modules? Not the Apple way. Go to Linux for that kind of thing. Who would use OS X for serious Perl work anyway?

WTF (0, Insightful)

Anonymous Coward | more than 5 years ago | (#26902169)

Is this even English?

Re:WTF (1, Informative)

Goaway (82658) | more than 5 years ago | (#26902417)

The person quoted is Japanese, in case you didn't notice.

Fighting over the same file (5, Insightful)

Ed Avis (5917) | more than 5 years ago | (#26902173)

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 (5, Informative)

warren.oates (925589) | more than 5 years ago | (#26902253)

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.

Re:Fighting over the same file (5, Insightful)

99BottlesOfBeerInMyF (813746) | more than 5 years ago | (#26902329)

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 (3, Informative)

King_TJ (85913) | more than 5 years ago | (#26902333)

Umm, what about Fink?

http://www.finkproject.org/ [finkproject.org]

Re: OS X and package management (4, Informative)

1stvamp (662375) | more than 5 years ago | (#26902389)

Or MacPorts, formerly DarwinPorts: http://macports.org/ [macports.org]

Re: OS X and package management (2, Insightful)

Jay Maynard (54798) | more than 5 years ago | (#26902527)

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: OS X and package management (2, Insightful)

truthsearch (249536) | more than 5 years ago | (#26902819)

Same here. I don't understand why I need the X11 sources compiled from fink just to get apache 2 and php.

Re: OS X and package management (3, Interesting)

SuperIceBoy (787273) | more than 5 years ago | (#26902973)

Same here. I don't understand why I need the X11 sources compiled from fink just to get apache 2 and php.

Not sure about on Mac, but on FreeBSD I define WITHOUT_X11 so that it doesn't do that.

Re: OS X and package management (5, Informative)

TJamieson (218336) | more than 5 years ago | (#26903185)

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.

Re: OS X and package management (1)

geekmansworld (950281) | more than 5 years ago | (#26903085)

Hear, hear.

Sometimes it's a pain to get the ./configure right on a build, but it can't possibly be more painful than dealing with the fact that dports and fink have a steep learning curve and don't PUT stuff in the RIGHT PLACES. Meaning I have to reconfigure my other programs to tell them where to find supporting libraries and programs.

If the build-savvy Apple community wanted to help distribute ports, they should just build a whole bunch of .pkg's. Until then, I'll stick with gcc-compiling from source.

Re: OS X and package management (1)

Jay Maynard (54798) | more than 5 years ago | (#26903123)

Amen. This is why Hercules [hercules-390.org] is distributed as a .pkg for OS X. I don't want to put Hercules users through the pain of dealing with Fink or MacPorts.

Re: OS X and package management (1)

Colonel Fahlt (1267662) | more than 5 years ago | (#26903243)

If you're going to the length of building from source yourself, you might also want to try pkgsrc.org [pkgsrc.org] , depending on your needs.

Re: OS X and package management (1)

warren.oates (925589) | more than 5 years ago | (#26902489)

What I meant was that there are no Apple-supplied package managers. Fink is a good add-on, but for some folks it's just got too much stuff in it. There's a good discussion here [oreilly.com] . While we're on that subject, there's also MacPorts [macports.org] .

Re: OS X and package management (1)

AlexCV (261412) | more than 5 years ago | (#26902869)

Fink and MacPorts both have the same problems:

1) It's impossible to successfully compile anything complex with 64-bit compiler flags (i.e.: -arch x86_64 -m64) since all libraries will be built without said flags... So you have to manually figure out all the dependencies yourself or backtrack the 32-bit install piecemeal.

2) X11 is/was often broken and needed XFree86 compiled instead of Apple's X11. This might have been dealt with in all cases now.

3) They are hopelessly behind every major O/S release. It took forever to have a 10.5 compatible fink and/or macport that was officially released.

All in all, I had to build a 64-bit application chain for 10.5/Intel and it took me two days to get ~30 packages compiled and linked successfully and fink/macport couldn't be used. I often had to reverse engineer fink mac patches for the packages that it did have, it's silly that I couldn't use fink to build them in 64-bit!

The rationale for a 64-bit build was a 40% performance improvement.

Re: OS X and package management (1)

Ash-Fox (726320) | more than 5 years ago | (#26902657)

Umm, what about Fink?

Fink has a tendency to have compile issues, segfaults etc. with random packages. ...

Then again, one gets the same problems generally under OS X when compiling the forementioned software manually, although it will generally work in more instances than Fink/Macports does.

Re:Fighting over the same file (0)

Anonymous Coward | more than 5 years ago | (#26902571)

Serious question. When they could use Debian instead, and given these problems, why does anyone use Apple servers?

Re:Fighting over the same file (2, Interesting)

morgan_greywolf (835522) | more than 5 years ago | (#26902837)

Some shops (mainly design studios, video studios, sound studios, etc., aside from the education market), use Macs almost exclusively and if you're going for a single-vendor solution to improve stability, supportability, etc., then that's why you'd want OS X on your server.

Personally, I think single-vendor solutions tend to trade a lack of flexibility, functionality and performance to get that stability, hence, I tend to favor 'best-of-breed' approaches, but to each his own.

Re:Fighting over the same file (1)

Bearhouse (1034238) | more than 5 years ago | (#26903627)

Personally, I think single-vendor solutions tend to trade a lack of flexibility, functionality and performance to get that stability, hence, I tend to favor 'best-of-breed' approaches, but to each his own.

Agree. You also avoid single point of failure and the "I know this, it looks just like my desktop..." 'superuser' toasting your server...

Re:Fighting over the same file (1)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#26902881)

Probably for roughly the same reason that people use Microsoft servers: If you want all the little secret sauce and special polish bits and bobs built into a company's client OS to actually work(and, if you are deploying large numbers of the things, yes, you do want this) then using their server OS is close to obligatory.

For basic commodity Unixy stuff, I have no idea why you would use Apple stuff(this doesn't necessarily mean Linux. Sun, for instance, makes the Unix server OS that OSX is (slowly) attempting to absorb features from, and has a much wider range of available server hardware).

Re:Fighting over the same file (3, Informative)

99BottlesOfBeerInMyF (813746) | more than 5 years ago | (#26903647)

Serious question. When they could use Debian instead, and given these problems, why does anyone use Apple servers?

If you're a sysadmin, I imagine it is because you need one of the few bits Apple does better right now (like CalDAV) or some Apple specific technology to support Mac clients (Spotlight Server).

If you're not a sysadmin, because you're looking for an easy to admin server that you don't need any real skills to get configured and keep running.

Re:Fighting over the same file (1)

Aram Fingal (576822) | more than 5 years ago | (#26902583)

You could help fix that problem by participating with projects such as Fink [finkproject.org] , MacPorts [macports.org] or OSXPM.

Re:Fighting over the same file (4, Informative)

pegdhcp (1158827) | more than 5 years ago | (#26902471)

Why are Apple's updater and Perl's CPAN shell both trying to update the same file?

Probably this is the real point, as mentioned in the TFA:

"This is another reason why you shouldn't use Perl that comes from vendors," Miyagawa says. "Apple isn't any different from Fedora on this!"

I might add Mandriva, SuSe and most others. Distribution managers want it just run and be stable for users who do not want to know what is going on inside. If there is a need for messing with details, originally packaged software by developer is the best alternative...

Re:Fighting over the same file (5, Insightful)

Alrescha (50745) | more than 5 years ago | (#26902811)

"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 (3, Insightful)

Ed Avis (5917) | more than 5 years ago | (#26903377)

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.

Re:Fighting over the same file (1)

Tanktalus (794810) | more than 5 years ago | (#26904001)

Yeah, until you update a package that breaks [vendor]'s supplied system administration tools, whether that be by accident (bug injection/exposure) or on purpose (bug fixed, but the tool relied on the broken behaviour). That seems like a fairly technical reason to me...

Re:Fighting over the same file (0)

Anonymous Coward | more than 5 years ago | (#26903111)

since when have any two package managers gotten along? Remember we're already talking about CPAN, which never seems to tell apt about what it's doing, or to pick up on what apt has already done, for example.

Until package managers learn to get along with eachother, none of this will ever work.

Re:Fighting over the same file (1)

Ed Avis (5917) | more than 5 years ago | (#26903513)

since when have any two package managers gotten along?

Never. My point is that having two different package managers operating on the same file is a bad idea. Each should keep to its own business and leave alone files managed by the other.

Re:Fighting over the same file (1)

cayenne8 (626475) | more than 5 years ago | (#26903963)

"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."

Or emerge......

:)

Why does this "break" anything? (4, Insightful)

mi (197448) | more than 5 years ago | (#26902183)

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:Why does this "break" anything? (0)

Anonymous Coward | more than 5 years ago | (#26902257)

Yes. This is one of the primary rules when updating an API - make it backwards compatible to the previous one. If you need to refactor it because it is a big pile of poo, then that's a major version number, and you can have both versions installed for backwards compatibility.

So something must require a new method on the API introduced in that .1 update. Big whoop.

Re:Why does this "break" anything? (-1)

Anonymous Coward | more than 5 years ago | (#26902263)

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?

No.

Re:Why does this "break" anything? (5, Informative)

Anonymous Coward | more than 5 years ago | (#26902343)

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.

Re:Why does this "break" anything? (5, Informative)

PerlDudeXL (456021) | more than 5 years ago | (#26902855)

This is a classic problem with most *nix distribution packages and CPAN usage. This is not Apple specific.

Re:Why does this "break" anything? (2, Informative)

ekidder (121911) | more than 5 years ago | (#26902391)

Well, 1.3 would be going backwards. 22 > 3 after all. Perl module versions can be a bit confusing. You'll find there are a lot of modules that break older versions.

Re:Why does this "break" anything? (1)

compro01 (777531) | more than 5 years ago | (#26902451)

The issue is that 1.23 is from over two years ago.

I believe the current version of CPAN shell is 1.93.

Re:Why does this "break" anything? (1, Informative)

Anonymous Coward | more than 5 years ago | (#26902597)

More importantly, 1.22 is the version of the IO module that ships with Perl 5.8.8, which is the version of Perl that ships with OS X 10.5.

They are simply keeping the version stable with the version they shipped. (And they only updated it because - due to the update in Perl - it would have broken otherwise.)

Re:Why does this "break" anything? (0)

Anonymous Coward | more than 5 years ago | (#26903745)

Calling Apple versions "stable" is an understatement, the binutils version that e.g. their iPhone SDK uses is (based on a version) about 12 years old and buggy as hell!

Re:Why does this "break" anything? (3, Informative)

fl!ptop (902193) | more than 5 years ago | (#26903009)

shouldn't the new version have been named 1.3 or even 2.0?

from the IO.pm changelog: [perl.org]

IO 1.23 -- Sat Mar 25 19:28:28 CST 2006

  • Adjust the regression tests to use t/test.pl when $ENV{PERL_CORE} is defined
  • Reduce number of calls to getpeername
  • Call qualify on format name passed to format_write. Bug reported by Johan Vromans
  • Reduce calls to getprotobyname/number. Patch from Gisle Aas
  • Remove references to file TEST used in core so appropriate tests are skipped during an install from CPAN
  • Add method say to IO::Handle
  • Performance improvement for IO::File::open
  • Don't warn about a directory being closed in the DESTROY

looks to me like it's mostly bug fixes and optimization, and not a major rewrite (which would more likely warrant a major version change).

Apple: Breakin' a bunch of crap recently (1, Informative)

Protocron (611778) | more than 5 years ago | (#26902301)

My wife's Mac just recently broke her only game (Sims 2) because of an Apple update. She updated Quicktime (we think) and that completely broke Aspyr's version of the Sims 2. http://support.aspyr.com/ [aspyr.com] "We are aware of the issues arising with the latest QuickTime update in 10.4.11 and are working with Apple to get it resolved. Please bear with us as we work with Apple to find the source of and fix for this problem." Yeah, nice work there Apple. What's next?

Re:Apple: Breakin' a bunch of crap recently (4, Funny)

elrous0 (869638) | more than 5 years ago | (#26902419)

All part of Apple's plan to ensure that no one can ever use a Mac for gaming.

Re:Apple: Breakin' a bunch of crap recently (2)

Doctor_Jest (688315) | more than 5 years ago | (#26902431)

Right. Let's see... Quicktime still works but the Sims 2 doesn't. Quicktime doesn't seem to break anything else, so logically, it MUST be Apple's fault. I think the rest of the Quicktime users who aren't playing the Sims 2 would disagree with your placement of blame. :)

Re:Apple: Breakin' a bunch of crap recently (1)

Stewie241 (1035724) | more than 5 years ago | (#26902499)

Well, what changed? Quicktime or Sims 2?

Re:Apple: Breakin' a bunch of crap recently (5, Funny)

Colonel Korn (1258968) | more than 5 years ago | (#26902515)

Right. Let's see... Quicktime still works but the Sims 2 doesn't. Quicktime doesn't seem to break anything else, so logically, it MUST be Apple's fault. I think the rest of the Quicktime users who aren't playing the Sims 2 would disagree with your placement of blame. :)

Brainwashed much? You're basically implying that if I hit you in the head with a hammer and you're knocked out, but the hammer, nearby mailbox, and tree are unharmed, that proves that the hammer isn't to blame - your head is.

Re:Apple: Breakin' a bunch of crap recently (1)

neuromanc3r (1119631) | more than 5 years ago | (#26903171)

[...] that proves that the hammer isn't to blame - your head is.

Well, actually that's not too far from the truth...

Re:Apple: Breakin' a bunch of crap recently (1)

steelfood (895457) | more than 5 years ago | (#26903199)

That's because the hammer didn't hit your head; your head hit the hammer!

Re:Apple: Breakin' a bunch of crap recently (1)

Drizzt Do'Urden (226671) | more than 5 years ago | (#26902523)

It's 1996 over again..

Remmember when a game made Win95 BSOD? It was the game that made the computer crash.

Remmember when a game made MacOS 7 bomb? It was the Mac that made the computer crash. Why? Because it's a frigggin' Mac!

The Sims 2 smeans to be quite borked. You can't move the App once it's installed or it will break it.

Re:Apple: Breakin' a bunch of crap recently (0)

Anonymous Coward | more than 5 years ago | (#26902547)

my thought exactly: wtf is sims doing with quicktime?

Re:Apple: Breakin' a bunch of crap recently (1)

Protocron (611778) | more than 5 years ago | (#26902641)

I would guess and say that it plays a video as you start the game. The intro screen shows something that looks like the name "Aspyr" in a flame and it says, "Aspyr." Then the intro plays that shows the Sims doing different actions (related to expansion packs.)
My guess is that they are all part of a Quicktime video.

Re:Apple: Breakin' a bunch of crap recently (4, Informative)

Tokerat (150341) | more than 5 years ago | (#26903345)

Quicktime is used on the Mac for much more than just showing a video - converting sound and image files from any format to any format (the reason my program can play AIFF, wav, MP3, AAC, etc is because Quicktime converts it to a stardard format for me). Therefore if the game is multiplatform like the Sims and all the sound effects are .wav files, Quicktime will probably be used as the standard API to convert them for playback.

Re:Apple: Breakin' a bunch of crap recently (1)

Protocron (611778) | more than 5 years ago | (#26902599)

I'm of two opinions here:

1) I agree with Stewie241. The Sims 2 was not updated, the Quicktime update broke something that was previous working.

2) That said, Aspyr sucks. They have many problems that we have never been able to resolve. Sims has a problem where the graphics kinda freak out and only shows the wire frames. Aspyr blames this on the differences in Apple drivers (ATI/Nvidia). And the expansion packs have frequently been the cause of teeth knashing (yeah I'm looking at you Bon Voyage.)

So Apple or Aspyr? I blame both. Apple isn't as great as it once was, and Aspyr just sucks.

Re:Apple: Breakin' a bunch of crap recently (1)

Kenshin (43036) | more than 5 years ago | (#26903141)

The Sims 2 was not updated, the Quicktime update broke something that was previous working.

That, or Sims 2 was using an "Undocumented Feature".

Re:Apple: Breakin' a bunch of crap recently (2, Informative)

DJRumpy (1345787) | more than 5 years ago | (#26902817)

Did you ever consider that Sims 2 may not have implemented Quicktime to Apples standard? Since nothing else appears to have broken, then it is also possible that Sims 2 has a poor or improperly coded implementation. As a designer, I'v done this myself a few times by not following the documentation.

Re:Apple: Breakin' a bunch of crap recently (1)

Gilmoure (18428) | more than 5 years ago | (#26902927)

SMAC/X is still working ok. 'Course, I had to track down a past developer of the Mac version to get a carbon version of the game engine to get it to work on an Intel Mac but no crashes in the last couple years. And it's on 24/7 on my home machine.

Here's why... (0, Troll)

bogaboga (793279) | more than 5 years ago | (#26902345)

I believe they believe Perl is dead...do they?

Re:Here's why... (1)

Icegryphon (715550) | more than 5 years ago | (#26903055)

Why is this tagged troll? I mean it is a valid question, does able believe this? They are not the only vendor with problems though.

What about the CPAN command line tool? (1)

Aram Fingal (576822) | more than 5 years ago | (#26902357)

I'm not having this problem so I can't verify but does the inability to update IO.pm still apply if you do: "$cpan -i IO" or only if you do use "perl -MCPAN?"

How will I regex? (1)

M4N14C (873188) | more than 5 years ago | (#26902367)

Real men regex in VIM!

Re:How will I regex? (1)

AndrewNeo (979708) | more than 5 years ago | (#26902649)

Or with grep.

Use CPAN? You deserve to lose (4, Informative)

Jay Maynard (54798) | more than 5 years ago | (#26902509)

CPAN is the closest thing to DLL hell on Unix systems. Modules are updated willy-nilly. No attempt is made to preserve compatibility between versions, or between modules and their dependencies. A company I used to work for had to totally abandon a large program because it was impossible to keep it working in the face of CPAN-driven upgrades, even if they did manage to get it installed the first time (by totally bypassing CPAN).

Re:Use CPAN? You deserve to lose (3, Insightful)

Anonymous Coward | more than 5 years ago | (#26902627)

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:Use CPAN? You deserve to lose (1)

$RANDOMLUSER (804576) | more than 5 years ago | (#26903269)

Perl as modern VHLL

Let me think about tha

HEAD ASPLODES

Re:Use CPAN? You deserve to lose (4, Informative)

Anonymous Coward | more than 5 years ago | (#26902707)

Huh? The opposite is true. CPAN, if anything, is more akin to a Linux distribution's package repository.

Would you say the same thing about, say, Debian's apt-get and friends?

Chances are you wouldn't, but that's exactly what CPAN's like. You have to use it correctly, though, and chances are that if you had trouble with it, you weren't.

(In particular, you should not blindly install updates all the time when there's no need, without even so much as testing them on non-production systems first. Again, consider following the trunk of any Linux distro, package-wise - would you expect things that aren't part of the distro to never break when libraries etc. are updated and new versions installed? Of course not.)

Re:Use CPAN? You deserve to lose (0)

Anonymous Coward | more than 5 years ago | (#26902991)

Chances are you wouldn't

The problem isn't CPAN alone. The problem is that using CPAN on a system that has some other installer installing other packages is like installing RPM on a debian system so you can install this one .rpm file (that probably was also available in a .deb, just like most cpan modules) then complaining when it blows up in your face.

Re:Use CPAN? You deserve to lose (1)

The Moof (859402) | more than 5 years ago | (#26902729)

CPAN is the closest thing to DLL hell on Unix systems

I don't know. Shared objects make a pretty good run for that title.

Re:Use CPAN? You deserve to lose (1)

stevied (169) | more than 5 years ago | (#26904007)

In the very old days, it seems like people were quite disciplined with shared objects: if a change didn't break backward compatibility, bump the minor version or revision number; if it did, bump the major number (the one that's treated as part of the library name, e.g. libncurses4 v. libncurses5)

Then somehow not long after glibc 2.0, things seemed to get a lot more complicated (or maybe I just got very confused). Anyone who wants to explain what goes on now would be very welcome; in the meantime I'm sticking with Debian & Ubuntu and apt-get ..

Re:Use CPAN? You deserve to lose (3, Interesting)

fl!ptop (902193) | more than 5 years ago | (#26902879)

CPAN is the closest thing to DLL hell on Unix systems

while i prefer centos for my production systems and don't use osx, i recommend implementing a solution i've found to work well. first, disable any rpmforge repos on your production machine. second, install new cpan stuff on your development server. test, then install on the production machine (if it passes the tests).

if you need a cpan module that's not available from the regular repositories, or from rpmforge, *never* install anything from cpan using make, make all, etc. always make an rpm using the makerpm.pl script, and install that instead. and never, ever install anything that's a Bundle::somepackage. build all the dependent packages by hand using makerpm.pl instead.

i've found that these methods help cool the 'dll hell' on my production machine. i rarely have any problems. i can't comment on how well this would work w/ a debian-based system that doesn't use rpm, however. not sure what kind of package management osx uses, either.

Re:Use CPAN? You deserve to lose (0)

Anonymous Coward | more than 5 years ago | (#26903793)

it was impossible to keep it working in the face of CPAN-driven upgrades

Can you explain what you mean by this? CPAN never upgrades a package unless you ask it to, in my experience. Once you have your program running there is no reason to upgrade CPAN modules, unless you have too much time on your hands.

I suspect your experience is unusual. I've enjoyed working with CPAN modules and I think most people who use Perl consider the project a huge success.

Scripting Languages not good for most applications (3, Interesting)

MrData (130916) | more than 5 years ago | (#26902533)

In the flamebait but true category, this is further evidence why scripting languages are not suitable for most application development ... because they are much more brittle than a traditionally compiled application. True you can site examples of traditionally compiled applications breaking due to missing dependencies, in which (like with this Perl example) the underlying deployment platform is a fault, but this type of problem is much more common with scripting languages (Perl, PHP, Python, etc), and vastly harder to debug and defend against.

Re:Scripting Languages not good for most applicati (1)

Stewie241 (1035724) | more than 5 years ago | (#26902717)

Hmmm... I do a lot of work in PHP and haven't had *too much* trouble with this. It has been fairly simple, actually. Where things get tricky is web server environments (not getting consistent variables in $_SERVER - SELF, etc.) and various configuration restraints that some hosts seem to think they need for security's sake. I've done work on a fairly significant script that runs on most version of PHP from 4.3 to 5.2 (a few exceptions of versions in there that are notoriously buggy).

Re:Scripting Languages not good for most applicati (1)

mr_mischief (456295) | more than 5 years ago | (#26903549)

It's common practice in the Perl community to keep the production tools separate from the OS distro's tools. Not only can the OS break your stuff, but if you're not careful you can break parts of the distro that depend on Perl.

Mandriva for one has many system tools that depend on a certain version. Fedora doesn't have this problem so much with Perl, but only because it does with Python.

Don't let your environments intermingle. You can even deploy an application written in Perl with its own copies of the modules it needs in its own directory quite easily. That means if one project needs a newer version of something, you don't even need to update other projects using older versions. You can share easily enough, but you can keep them separate too.

Super bad for Servers (5, Informative)

geekmansworld (950281) | more than 5 years ago | (#26902543)

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.

Re:Super bad for Servers (0, Redundant)

Ash-Fox (726320) | more than 5 years ago | (#26902587)

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.

I completely agree.

Mod parent up.

Re:Super bad for Servers (2, Interesting)

tbuddy23 (1178415) | more than 5 years ago | (#26902775)

If you don't look at every file or at least the general path of what you are installing then you deserve it. Fink, SuspiciousPackage and the like all are very good for this.
If you need excessive amounts of PERL modules why aren't you using a generic *NIX server rather than OS X Server? The only compelling reasons I could use for using OS X Server is 1) Provide excellent AFP file services 2) You really love Mac OS X and want the whole barrage of services in the form of one mediocre server. I think Windows has an offering like that coming out soon in the form of Window Small Business Server 2008.

Re:Super bad for Servers (1)

mr_mischief (456295) | more than 5 years ago | (#26903577)

To be fair to Apple, it's considered good practice to not manage the modules provided by the distro with CPAN on Unix/Linux systems in general. Let the distro manage its own updates and manage updates of stuff you got from CPAN using CPAN.

Re:Super bad for Servers (5, Interesting)

ducomputergeek (595742) | more than 5 years ago | (#26902789)

I love Apple laptops and desktops. Hate Xserve and I've found OSX-Server to be nothing to write home about. When I was an Apple Certified consultant, I saw a much higher than average failure rate with Xserve hardware. It got to the point to where we'd only deploy OSX-server on PowerMac/MacPro machines. I know some people love their OSX-server tools admin package. It is a pretty slick GUI. I will give them that. But really, I can do just about anything OSX-Server can on a default OSX install. And for the price, I can build reliable servers with FreeBSD a lot cheaper with the same functionality, and arugably even more functionality than OSX-Server.

Um, hello moderators? (1, Funny)

Tokerat (150341) | more than 5 years ago | (#26903291)

Good points and all, man, but um...

-1: Offtopic

Re:Super bad for Servers (1, Insightful)

geekmansworld (950281) | more than 5 years ago | (#26902931)

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?

Re:Super bad for Servers (3, Insightful)

fuzzyfuzzyfungus (1223518) | more than 5 years ago | (#26903189)

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?

Hear Hear (for client, too)! (4, Informative)

MisterSquid (231834) | more than 5 years ago | (#26903511)

Apple seems to have a separation between its left-brain UNIX underpinnings and its right-brain Quartz GUI.

For example, with the last several Security Updates, which contain very little information about what all's rolled in, Apple modifies /etc/postfix/main.cf

inet_interfaces = all

to

inet_interfaces = localhost.

This effectively breaks all Internet-accessible postfix installs. Now, the question is why does Apple apply this to postfix installations explicitly enabled as Internet-accessible? I can't think of any good answer for this except as part of some other bass-ackwards security measures Apple applies in a schizophrenic attitude to the server functions of its UNIX-based client OS.

For another example, the Aiport Extreme Base Station prior to firmware 7.3.1 had a version of DMZ host (default host in Apple bizarro-world) that worked flawlessly. In April 2007 or thereabouts, Apple rolls out firmware 7.3.1, since which default host is broken for only for BIND (UDP port 53) and all mail ports (587, 110. 995, etc) but works for WoW, BitTorrent, and all other ports. WTF?! If I set my router to designate one computer as the default/universal host, why is it still blocking certain ports that have to be opened using port mapping?

This split-mind on UNIX vs. GUI seems to pervade Apple's mentality everywhere which is especially problematic to people like me that are not full-time developers but make extensive use of UNIX-layer services.

Really stupid stuff, Apple. I wish you'd cut it out.

Progress! (1)

rockmuelle (575982) | more than 5 years ago | (#26902743)

1990s ... Apple stops using 5 1/4" floppies in favor of 3 1/2" disks ... Apple standardizes on Firewire/USB, obsoletes parallel and RS-232 ports ... Apple stops using floppy disk drives all together
2000s ... Apple introduces LCD iMac, no longer sells CRTs ... Apple locks the battery in the MacBook Air - replacable batteries obsolete! (ugh) ... Apple breaks Perl in OS X, the world moves away from write-only languages

*ducks*

-Chris

Re:Progress! (3, Informative)

morgan_greywolf (835522) | more than 5 years ago | (#26903005)

Not to pick nits too much here, but

1) Apple stopped using 5.25" FDDs well before the 1990s. Every Mac that came with a floppy drive from their inception in 1984 came with a 3.5" FDD.

2) You can always buy a third-party CRT if you want a CRT on your Mac, iMac excepted (obviously). Aside from that, having used expensive color-calibrated displays and printers and so forth with high-end color management, etc., I'll let you all in on a big secret: There's no such thing as true color matching. The laws of physics don't allow for it (light vs. pigment).

3) By the time most need to replace the battery in your notebook, it's usually time to get a new notebook. ;)

4) Another big secret: It's perfectly possible to write clear, self-documenting code in Perl. It's only the fact that Perl programmers seem to refuse to do this that allows Python to exist ;).

People still use perl. (-1, Offtopic)

jellomizer (103300) | more than 5 years ago | (#26902897)

I though people stopped using Perl after they left college and the Drugs left their systems, and the current lower enrollment of CS students made sure this was under control.

Sorry Perl and Me never meshed. More of a Python Fan.

you never update a live system .. (1)

viralMeme (1461143) | more than 5 years ago | (#26902923)

"It looks like if you use CPAN to install modules, Apple's latest security update might just have broken your Perl"

Doesn't matter, no one in his right mind updates a live system. Especially with some third-party update package, never nada ...

Didn't break my Perl, did break Catalyst (3, Insightful)

Kostya (1146) | more than 5 years ago | (#26903041)

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.

Time to migrate (1)

AntEater (16627) | more than 5 years ago | (#26903057)

I guess it's time for me to learn python.

Perl already broken (0)

Anonymous Coward | more than 5 years ago | (#26903079)

Perl was already broken by design. Ba doom, crash. I'll be here all week ladies and gentleman.

Easy fix: Stop changing Apple's files. (2, Insightful)

Trillan (597339) | more than 5 years ago | (#26903317)

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.

Why did the installer allow this? (1)

MobyDisk (75490) | more than 5 years ago | (#26903889)

Why did the updater/installer even allow a file to be overwritten with a previous version? Does it not skip files if the one already present is newer?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>