changing default perl

[Clemens Lang]

On Sun, Nov 03, 2013 at 07:30:48PM -0600, Ryan Schmidt wrote:
> I believe the reason is because perl is a programming language, and
> programming languages are used by end users, not just by other ports.

I agree with that, but I still think we're pushing this to the extreme
here. I think the difference between PHP (where I agree with your
reasoning) and Perl is that way more ports depend on Perl than on PHP.

The same approach we currently use for PHP and Python could be applied
to Perl as well, but that would mean touching each and every port that
uses Perl, adding Perl variants, making sure those ports use the correct
Perl, etc. - a huge maintenance headache for the benefit of having
multiple minor versions of Perl that are largely compatible.

There are a couple of disadvantages to this approach:
 - Modifying and testing lots of ports
   Every port in port echo depends:perl5 and not p5* would have to be
   modified. Currently 77 ports directly depend on perl5.
 - Maintaining Perl variants for each port using Perl
   Every new minor Perl release would require us to modify all ports to
   add a variant for the new Perl. We already do that for the other
   language ports, but I personally think it's a heavy maintenance
   burden.
 - We do not keep track which variants were requested specifically by a
   user, and which ones were installed because they were the default.
   This leads to situations that require manual intervention by a user
   when trying to update his/her Perl version (and we cannot determine a
   point in time where the majority of users should switch). We've seen
   another instance of this problem with +llvm variants and LLVM 3.0
   being no longer supported on Mavericks, requiring lots of users to
   manually adjust their package selections. [1]

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

While I wonder who is actually using MacPorts and Macs as servers, let's
not argue about this here and at this time and just agree that we'll
keep Python, PHP and MySQL as they are at the moment, concentrate on
Perl and try to review whatever we're going to implement later to see if
that would be a feasible approach for those as well or not.


On Sun, Nov 03, 2013 at 07:47:55PM -0600, Ryan Schmidt wrote:
> Actually here’s the ticket from 5 years ago that willed the perl5
> metaport into existence, along with some discussion about whether it
> would be nicer to just have a single perl:

OK, so I read through this ticket, and it seems this approach did work
reasonably well once (it went from perl5.8 to 5.10 to 5.12), but then
got stuck somehow. Then, we added perl5.12 as a hardcoded dependency to
many ports and de-facto chose a single blessed Perl version that almost
everybody [2] has uses.

The ticket mentions the need to rebuild all Perl modules after a version
bump and proposes a method to do that automatically in #17473, which is
closed wontfix because of rev-upgrade (which doesn't deal with Perl
modules, and doesn't avoid the manual rev-bumps either). I think we've
grown accustomed to rev-bumping large numbers of ports, and while there
are lots and lots of Perl modules, I guess this could still be done
using a semi-automatic approach in adding revision lines or increasing
them. So, let's assume the revbumps required for all Perl modules
wouldn't be a show-stopper for a single Perl version.

Another valid point from the ticket is that non-Perl ports sometimes
install Perl bindings for whatever `/opt/local/bin/perl` currently is -
having a single Perl version would make those less of a headache at one.

A first measure could be changing perl5's default variant to 5_16 (or
5_18 after adding that). That would not affect most users for now, but
would gradually uncover problems caused by those versions.

And then after a while, when some users have switched and we know
everything is working fine, we could just drop all old Perls and old
Perl modules and move whatever perl5.something port is current at this
time to perl5 while also adjusting the PortGroup to do the same
transition.

Btw, even /usr/bin/perl is 5.16 as of Mavericks…

Let me close this rather long mail with a money quote from #16380 by
mcalhoun:
  "We have also avoided the fate of python, where each port must take
   into consideration 2 to 4 different versions of python."

-- 
Clemens Lang

[1] Yes, I know following Migration prevents that on OS upgrade, but
    let's be honest and admit not everybody follows the Migration
	exactly. Plus, this issue can come up without OS upgrades.
[2] We should really get those statistics going.