changing default perl

[Ryan Schmidt]

On Nov 3, 2013, at 16:44, Clemens Lang wrote:

> To be honest, I don't know why we've ever diverged from this strategy.
> We're in a habit of shipping the latest and greatest version of software
> for most ports we have, sometimes even if breaks dependents (in which
> case we try to fix the dependents or get upstream to fix them for us).
> Maybe somebody who has seen the transition back then can comment on
> that?

I believe the reason is because perl is a programming language, and programming languages are used by end users, not just by other ports. For example, the ability to install and use php55 or php54 or php53 may be a reason why someone installs MacPorts. And sometimes those languages change between releases, causing incompatibilities. For example, php5 added new reserved words. If you had a php4 web site that happened to be programmed with variables whose names became reserved words, your site would break in php5. And there have been breaking changes between minor versions of php as well. If you had a port that broke with a newer php version, we MacPorts developers could fix that port, but we MacPorts developers cannot fix php code the user has written on their own disk.

Thus there is continued interest in being able to install older versions of languages to be able to run one’s own older scripts, either because one does not have time to update them for newer versions of the language, or to see how they work while one is in the process of updating them for newer versions of the language.

These languages—php especially but conceivable perl as well—could be employed to power programs running on a server, such as a web site. I would not want a major or minor version update of a port to cause somebody’s web site or server to fail because of an unanticipated change in the programming language.

You mentioned MySQL. We offer versioned ports for databases as well, because they too run on servers and have to stay running. Upgrading to a new version of a database may involve the need to run database update scripts, and the SQL language in MySQL may have changed or gained new keywords as well, which could cause similar problems to the above.


On Nov 3, 2013, at 17:05, Mark Anderson wrote:

> Perl has a tendency to go out of its way to not break backwards compatibility to an almost annoying degree, so I would hope the impact could be minimal.

This may be the real difference in perl vs the other languages, and a reason why we might not need to keep so many versions of perl around.


> And until Perl6 comes along, the benefit of staying on 5.16 vs. 5.18 is hard to see. When we get to perl6, it will be much like python 2 vs. 3 and I can see keeping both around.

However I assume we would want to keep separate perl5 and perl6 worlds, so the existing perl infrastructure we have in MacPorts might be suitable to accomplishing that.