I bugged an Influential Friend at Apple about the Perl upgrade issue, hoping that he would have a Wonderfully Authoritative Solution to offer:
As you may recall, OSX ships with version 5.6.0 of perl:
[EMAIL PROTECTED] [~] 18: perl -v
This is perl, v5.6.0 built for darwin ...
Given that 5.6.1 (a bug fix release) has been out for quite a while, one could ask why Apple hasn't pushed it into an update. But that's not the critical issue, at lease for me (and assorted folks on [EMAIL PROTECTED]).
I want to be able to ship installable (e.g., mpkg > dmg > bin) packages that depend on XS-based modules (e.g., CamelBones). More to the point, I'd like these packages to keep working when Apple upgrades its version of perl. Several months have gone by, but I haven't heard any "formula" that seems to accomplish this. So, wazzup?
Unfortunately, he didn't have any answer to offer:
I don't think there is any such formula. Perl gets upgraded, packages break, it appears to be a fact of life in the Perl world.
Fortunately, he's quite willing to listen to (workable) suggestions:
If you know of some magic bullet here, we're all ears. :)
So, gang, can we brainstorm up a solution that meets our needs AND is sanitary and safe for Apple to implement? (It would be REALLY BAD to solve this problem and create a bigger problem in the process. :-)
I think the best place to begin is by defining the problem, as clearly as possible. I'll give it a try, then Sherm and Dan and the rest of you can point out the things I get wrong. A bazaar approach; I know...
If OSX were to upgrade its Perl to 5.6.1, using the same compile options and such, nothing that is dependent on the current perl binary _should_ break. So, this seems like a fairly safe move which would move us past some known bugs.
OTOH, version 5.8.0 has been out since mid-July (5.8.1 is under discussion on [EMAIL PROTECTED], but nothing seems imminent; besides, shouldn't a 5.8.1 upgrade be transparent?). Anyway, here's the story on 5.8.0:
"The most important new features are enhanced Unicode and threads support, and the new I/O subsystem called PerlIO, but there are lots of new goodies, not to mention bazillion bugfixes."
-- Jarkko Hietaniemi, on http://www.perl.org
Enhanced Unicode and thread support could both be important for writing Real Apps under Cocoa. Bug fixes are also a Good Thing. So, moving to 5.8.0 will be important in the long run, even if it isn't critical for most of us right now.
Also, new versions of Perl will no doubt emerge over time. In the Linux and BSD communities, this is no big deal; we're always installing new releases (and dealing with the consequences :-). Apple, however, has this silly idea that OS software should be stable and reliable for YEARS. OS upgrades (particularly dotdots) aren't supposed to break things. If Perl is to be considered a Real Language for OSX development, we need a way to allow these upgrades to take place i_n_v_i_s_i_b_l_y. Really.
As an aspiring OSX developer, I'll have to say that I approve of this. I have NO interest in dealing with mass breakage of my apps, caused by a Perl upgrade. I want my apps to sail through any upgrade, allowing me to slip in _my own_ upgrade(s) in a calm and controlled manner.
Several issues have to be handled to make this work:
* language changes
If the Perl upgrade introduces incompatible language changes, apps
may break. There doesn't seem to be much of this in 5.8.0 that
affects Mac OS X; the only possibilities I see are:- Attributes For my Now Handled At Run-Time
- REF(...) instead of SCALAR(...)
- Unicode Model Changed (no more "use utf8", almost)
-- http://dev.perl.org/perl5/news/2002/07/18/580ann
* module changes
If a Perl upgrade removes a module or changes it incompatibly, things
could break. I don't see anything of this nature, however, in 5.8.0.* perl(1) binary changes
Here's where things get sticky:
"Mainly because of the PerlIO introduction, Perl 5.8 is not binary
compatible with any earlier Perl release; XS MODULES WILL HAVE TO
BE RECOMPILED!"It sounds as if this will require two versions of perl(1) and two sets of any XS-based modules. Can we do this in a way that works for command and apps, alike? Inquiring minds need to know...
-r -- email: [EMAIL PROTECTED]; phone: +1 650-873-7841 http://www.cfcl.com/rdm - my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
