I'll chime in as an OSX user and perl user. I think you need to
define this a little better.
Pardon me for a long post of no code or even design, but I think as a
direction I need to get this clear to myself. This applies to any "distribution"
of an OS which includes Perl (or any other language) which is not controlled
by distribution owner. Putting on my corporate hat and using jargon:
What is Apples service level agreement to with users in regard to
development tools included with OSX that are NOT directly controlled by Apple?
I think this goes beyond perl. Let me just suggest some possible levels of support (Your friend
at Apple would really need to make this explicit.) and their
implications.
A. Minimum Level -
1. Apple makes sure the "language engine" (compiler/interpreter plus
included libraries) functions under the current revision of OSX and any
Apple distributed Modules work with that rev level of engine and OS.
2. Whenever Apple releases a new version it makes sure any Modules and
programs it has released work with the new version.
3. Apple makes no effort to keep to any particular latest revision.
4. Any user supplied modules are guaranteed nothing across a revision.
It is up to users/writers to come out with compatible versions.B. Higher Level
1. A1 and A2 stay same.
2. Apple tries to stay reasonably close to leading edge revision of
language engine.
3. Apple attempts to make compatible interfaces so third party apps
continue to work with new revision.
ok we can stop right here because this is already to much of a burdon
on Apple or anyone ....I think the current situation is A with Apple fine with B2 if possible.
so what about a different direction with "Engine" developers having a responsibility:
C. Core + other
1. Apple makes sure the "language engine" (compiler/interpreter plus
included libraries) functions under the current revision of OSX and any
Apple distributed Modules work with that rev level of engine and OS.
2. Whenever Apple releases a new version it makes sure any Modules and
programs it has released work with the new version. This "version"
shouldn't change in Module compatibility until major OS changes when it
could make a jump to new major revision if possible. Small revisions
could be applied for security etc, but should not break interface
compatibility except for some sev 1 issues (like major security issue
or something).
3. The language engine should be designed so it is easy for more than
one version (at least two but preferably any number) to
co-exist with tool chains able to function totally independently. This
is a "service level" that the language "owners" need to support.
4. Apple would then "bless" the means to switch to the different
versions. What does this mean? In practice it means that if there were
two copies of the language engine exactly as Apple released it, one in
the default location and one in another location and independent, then
whatever means that would be used to "switch" would be ok'd by Apple,
and all the things that Apple provided that worked with one version
would work with the other. That is, the location of the distribution
shouldn't matter to Apple. The distribution used should be able to be
chosen at the application program level also, but also the "default"
system distribution should be settable via environment, init, Netinfo,
or symlink change or whatever.
5. If the "other" version is switched in Apple has no responsibility...I think option C or something like it would be the way to go. It would mean that language developers could "switch in" their newer versions and see how they would work and Apple could still depend on a consistent version for its use.
It would also allow Apple to upgrade to newer versions while still having an out if someone is depending on an older version. Simply have the new Apple version and the old Apple version available, then Apple can tell users, no problem - switch back as Apple moves forward. This would be really nice for Server folks (speaking as someone who has to plan for 100's of servers from 15K's to Blades.) since they could upgrade on their timetable.
OK enough generics. Is this the direction to go? If so I think that there is some effort, but not a huge amount split between apple and perl developers.
Perl Developers work
1. Make sure we can have multiple distributions co-exist with no interaction. Much of this is already there. There may be some unresolved issues. The work would be documenting exactly how to do this under Macosx and how to have modules point to where we want. 2. Making sure that all the modules Apple uses (modperl...) work with whatever distribution wanted - responding to discoveries below.
Apple's Work 1. Documenting all Perl scripts and modules used with OSX distribution (probably already exists). 2. Creating documented method to switch default distribution locations (e.g. change a link in standard directory maybe plus?) 3. Checking that all stuff under #1 would still work when pointing to another distribution. From Apples point of view it can actually be the same one for test. Changing what is needed to make this switch work. If there are perl related things that cause this to fail, then notify perl5-porters or [EMAIL PROTECTED], say, to have them worked on.
If this was done then I think we could get things like apt-get perl distributions as well and Apple would have to do less work qualifying new versions since if people could run them - they could get a level of confidence in use aside from whatever regression tests they may do.
Having said this I now have to get off my behind and look at the recipes out there now to replace
and build separately...
I think parrot/perl6 should definitely be able to be built this way also....with multiple active distributions possible in a system.
Hope this rambling helps... Mark Kaehny
On Thursday, February 27, 2003, at 02:09 AM, Rich Morin wrote:
[ I posted this on [EMAIL PROTECTED], 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:
[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
