Re: perl 5.8.5

On Wed, 6 Oct 2004, Ryan Newman wrote:

>> Even though I have hit some of these problems, I do think it is a
>> good idea to make the change to 5.8 as part of FreeBSD 5.3-release.
>> People should be taking a bit more time to check, cross-check, and
>> re-check everything they are running if they are upgrading to
>> 5.3-release from 4.x-release.
>> 
> 
> Having 5.3 default to perl 5.8 will add a lot of delay in several peoples
> migration from 4.x for sure.

Uh, I don't really understand this argument at all.

I happen to be one of the "lucky" people administering a couple of huge, 
complex, perl-based applications, currently running on 4-STABLE servers and 
perl 5.6 from ports. These are systems that are inherited after mergers, and 
none of the original developers are available anymore. They are also written 
with a lot of sloppy perl code, and break rather spectacularly with 5.8, which 
seems to be a lot more strict in checking certain types of syntax. Now, since 
people around here tend to value their sanity (and therefore also mostly use 
Python, C or PHP), nobody really wants to touch these apps until they are 
phased out and replaced sometime in the next couple of years.

However, one of the big differences between 4.x and 5.x is that perl is not in 
the base system on 5.x but rather just a package - therefore I actually 
consider it EASIER to move these systems to new servers on 5.x than moving them 
to new boxes on 4.x. If perl 5.8 is the default, well, pkg_delete it and add 
5.6, problem solved. If I can select 5.6 directly from sysinstall, even easier. 
I don't really care what sysinstall tries to do by default.

Since said systems are very CPU-intensive and threaded, we eagerly anticipate 
5.3-RELEASE to take advantage of the new SMP code - I've already set aside a 
lot of testing time over the next few weeks to play with lifting these apps 
over to a 5.3-BETA/RC and measure the performance on some multi-CPU Xeon 
systems, and hopefully keep these apps running until their replacements are in 
place - since "throwing hardware at the problem" has really been taken to its 
limits on their current 4-STABLE incarnations.

/leg