develooper Front page | perl.perl5.porters | Postings from February 2003

Fwd: magic bullet needed for Perl upgrades on Mac OS X

Rich Morin
February 27, 2003 00:09
Fwd: magic bullet needed for Perl upgrades on Mac OS X
Message ID:
[ I posted this on, because the issue is important to
   everyone on that list.  OTOH, some of the folks on this list may be
   interested enough to drift over and take part in the discussion, so
   I'm copying it to this list, as well.  Please don't post Mac OS X
   upgrade strategies to p5p; it will just split the discussion.  -r ]

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:
>    rdm@cerberus [~] 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
>  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, 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

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)


   *  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

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

email:; phone: +1 650-873-7841    - my home page, resume, etc.   - The FreeBSD Browser, Meta Project, etc. - Prime Time Freeware's DOSSIER series     - Prime Time Freeware's Darwin Collection Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About