RFE: Have only one perl5 package

[mcalhoun@…]

Is there a compelling reason why there are two packages for Perl 5?
May I suggest that perl5.8 be removed and perl5.10 become perl5.

• perl5.8 is unmaintained.
• Perl 5.10 has been been the official Perl since December.
• It would preclude the need for some sort of perl_select package.

I am not an expert in Perl development, so perhaps there are good reasons for keeping perl5.8 around, but if not, then having just one perl5 package would be a relatively easy (and simplifying) change to make.

[dluke@…]

CPAN still lists 5.8.8 as recommended for stable production use, which would be a good reason to keep it around.

I think defaulting to 5.10.0 and having it install ${prefix}/bin/perl and requiring anything that wants to have the older perl5.8 to use ${prefix}/bin/perl5.8 instead would be good, though.

(and/or something like perl_select).

[afb@…]

Asked this on the mailing list earlier, but there were no real decisions made:  http://lists.macosforge.org/pipermail/macports-dev/2007-December/003911.html

So it was easiest to just leave it, as Perl had bigger issues with the modules. But deleting /opt/local/bin/perl and adding a perl_select isn't too complicated.

[dluke@…]

Cc Me!

[afb@…]

Is there a compelling reason why there are two packages for Perl 5?
May I suggest that perl5.8 be removed and perl5.10 become perl5.
* perl5.8 is unmaintained. * Perl 5.10 has been been the official Perl since December.

As originally proposed, this suggesstion is a non-starter... It would be rather unusual for one port to disappear and to change the name of the "perl5.10" port (odd as it is).

However, changing the "default perl" to Perl 5.10 is certainly doable even if annoying due to all "port:perl5.8"

The other misunderstanding is that perl5.10 is maintained, I'll clear that up.

[mcalhoun@…]

How about this strategy?

• Create a perl5 package.
• perl5 would install ${prefix}/bin/perl (no version appending).
• perl5 would initially use version 5.8 since 5.10.0 is still a test release.
• When 5.10.1 is released, then perl5 would switch its ${version} to 5.10.
• perl5 would use the latest maintenance Perl 5 version (5.12 etc).
• perl5-1.0.tcl would be modified to depend on perl5 (instead of perl5.8).

A big advantage is that this strategy avoids the need to have separate p5-* packages for each Perl 5 version (as happened with Python).

To accommodate perl5

• perl5.8 and perl5.10 would be modified to avoid conflict with perl5.
• Packages which depend on port:perl5.8 would have to be changed immediately.
• Packages which depend on path:${prefix}/bin/perl:perl5.8 or bin:perl:perl5.8 should be changed eventually.

Are there any thoughts on this strategy?
I would be happy to do the heavy lifting on any changes (including changing unmaintained ports).

[dluke@…]

That seems OK to me, although I'm also happy with just having perl5.10 become the default perl for us already.

The one issue I still see would be with upgrading, an unknown number of p5 ports that were installed for perl5.8 would need to be rebuilt to work with perl5.10 - and we don't have a good way of exposing that to macports (usually in cases like that, we end up resorting to rev-bumping things that haven't changed so that people rebuild them).

I would lean towards having perl5.8 no longer install ${prefix}/bin/perl, have perl5.10 do that, and update the group code and other ports to depend on perl5.10 unless they specifically need perl5.8 for some reason.

[And then someone needs to tackle the whole @INC ordering or other work-around for building newer versions of modules that get installed with the perl port.]

[febeling@…]

Cc Me!

[vinc17@…]

Cc Me!

[vinc17@…]

Replying to dluke@…:

That seems OK to me, although I'm also happy with just having perl5.10 become the default perl for us already.

I agree with that. Perl 5.10 will even be in Debian/stable. So, I suppose that the main problems have been solved.

[And then someone needs to tackle the whole @INC ordering or other work-around for building newer versions of modules that get installed with the perl port.]

I'd say that for the time being, there is no need to replace core modules with perl 5.10 (since it is recent enough). But the problem may arise in the future.

[ricci@…]

Cc Me!

[ricci@…]

Replying to mcalhoun@…:

How about this strategy? * Create a perl5 package. * perl5 would install ${prefix}/bin/perl (no version appending). * perl5 would initially use version 5.8 since 5.10.0 is still a test release. * When 5.10.1 is released, then perl5 would switch its ${version} to 5.10. * perl5 would use the latest maintenance Perl 5 version (5.12 etc). * perl5-1.0.tcl would be modified to depend on perl5 (instead of perl5.8). A big advantage is that this strategy avoids the need to have separate p5-* packages for each Perl 5 version (as happened with Python). To accommodate perl5 * perl5.8 and perl5.10 would be modified to avoid conflict with perl5. * Packages which depend on port:perl5.8 would have to be changed immediately. * Packages which depend on path:${prefix}/bin/perl:perl5.8 or bin:perl:perl5.8 should be changed eventually. Are there any thoughts on this strategy?
I would be happy to do the heavy lifting on any changes (including changing unmaintained ports).

I don't think we should switch to perl5.10 yet - as was noted its still in 'testing' and for those of us that use perl for "production" work using a 'testing' version is a Bad Thing(tm).

I like the concept of a common perl5 port that can cover perl5.8 and perl5.10 (and ideally, later). I'm not seeing how this will work, given that some perl modules will need to be recompiled if a user switches between perl5.8 and perl5.10, and we don't have a way for macports to know about those modules (as dluke has pointed out).

I don't think we should alter perl's @INC to use a common space (for those that don't know, perl creates versioned directories for modules, aka ${prefix}/lib/perl5/5.8.8/, ${prefix}/lib/perl5/vendor_perl/5.8.8/) as that will make it impossible to have both perl5.8 and perl5.10 (and later versions) installed at the same time.

Hmmm. If we have something that sets the 'active' perl version, and we teach 'port' (presumably something in the perl portgroup...) how to read that, that might just get us to the point where port does know if it needs to rebuild a perl module or not. Do we have anything like that now?

p.s. I've taken maintainership of both perl5.8 and perl5.10 (with openmaintainer). If anyone else wants to share please feel free to add yourself or drop me a note and I can add you.

[dluke@…]

Replying to ricci@…:

I don't think we should switch to perl5.10 yet - as was noted its still in 'testing' and for those of us that use perl for "production" work using a 'testing' version is a Bad Thing(tm).

It's 'testing' as opposed to 'maintenance' and is what is recommended for new installs.

I don't think we should alter perl's @INC to use a common space (for those that don't know, perl creates versioned directories for modules, aka ${prefix}/lib/perl5/5.8.8/, ${prefix}/lib/perl5/vendor_perl/5.8.8/) as that will make it impossible to have both perl5.8 and perl5.10 (and later versions) installed at the same time.

The @INC changes I was referring to would let us install perl modules of more recent versions than the included modules and have a simple 'use module;' pick up the new version. There should be at least one open ticket that discusses this (along with other possible solutions). vinc17 is right, though, that that won't be an immediate issues since perl5.10 doesn't have the same problem with outdated core modules as per5.8 does.

[ricci@…]

Replying to dluke@…:

Replying to ricci@…:

I don't think we should switch to perl5.10 yet - as was noted its still in 'testing' and for those of us that use perl for "production" work using a 'testing' version is a Bad Thing(tm).

It's 'testing' as opposed to 'maintenance' and is what is recommended for new installs.

Their language isn't the best (on  http://cpan.org/src/README.html), they start off the paragraph with:

For stable production use the maint branches are recommended.

Then end the paragraph with:

but you should still start using them.

To me that says they want you to use 5.10.0 so it gets widespread testing, but if you have production-quality needs, you should use a version that's in 'maint' rather than 'testing'. I don't see anywhere else where 5.10.0 is recommended for new installs.

I don't think we should alter perl's @INC to use a common space (for those that don't know, perl creates versioned directories for modules, aka ${prefix}/lib/perl5/5.8.8/, ${prefix}/lib/perl5/vendor_perl/5.8.8/) as that will make it impossible to have both perl5.8 and perl5.10 (and later versions) installed at the same time.

The @INC changes I was referring to would let us install perl modules of more recent versions than the included modules and have a simple 'use module;' pick up the new version. There should be at least one open ticket that discusses this (along with other possible solutions). vinc17 is right, though, that that won't be an immediate issues since perl5.10 doesn't have the same problem with outdated core modules as per5.8 does.

Yes, I read that your description of the @INC change was the inversion of the @INC paths so that the macports-installed versions would be picked up first (I see tickets #12710 and #12950 exist about this, there may be more), I was commenting more about the dangers using a non-versioned @INC path. I'm all for doing the @INC inversion (ala FreeBSD ports).

[dluke@…]

Replying to ricci@…:

Their language isn't the best

I totally agree.

To me that says they want you to use 5.10.0 so it gets widespread testing, but if you have production-quality needs, you should use a version that's in

'maint' rather than 'testing'. I don't see anywhere else where 5.10.0 is recommended for new installs.

 http://www.perl.org/get.html "Stable Release -> Perl 5.10.0, Previous Stable Release -> Perl 5.8.8"

Debian/stable picking up 5.10.0 is indicative of its status as well.

Yes, I read that your description of the @INC change was the inversion of the @INC paths so that the macports-installed versions would be picked up first (I see tickets #12710 and #12950 exist about this, there may be more), I was commenting more about the dangers using a non-versioned @INC path.

Yep. (I'll leave it to others to decide if those problems are easier or harder to solve).

I'm all for doing the @INC inversion (ala FreeBSD ports).

[vinc17@…]

Replying to ricci@…:

I don't think we should switch to perl5.10 yet - as was noted its still in 'testing' and for those of us that use perl for "production" work using a 'testing' version is a Bad Thing(tm).

With this reasoning, MacPorts should never replace a core module by a later version, because this later version is in testing (or worse). This means that the change of the @INC path must not be global, but should be done locally by software that needs later versions.

[dluke@…]

Replying to vinc17@…:

With this reasoning, MacPorts should never replace a core module by a later version, because this later version is in testing (or worse). This means that the change of the @INC path must not be global, but should be done locally by software that needs later versions.

That would only be true if the module authors only released 'stable' versions of those modules with 'stable' versions of perl (which isn't the case).

So, while I appreciate the attempt at argument (and even agree with the conclusion of having perl5.10 be the default), it doesn't really follow the same logic.

[vinc17@…]

Replying to dluke@…:

That would only be true if the module authors only released 'stable' versions of those modules with 'stable' versions of perl (which isn't the case).

Only versions that goes back to the stable branch in question (e.g. because an important bug is fixed) are stable (individual authors of core modules can't decide for the whole project). But in such a case, you don't need a separate port for these modules: the upgrade of the perl port would be sufficient. BTW, that's the whole point of the stable status: don't introduce changes that could affect other software, just fix bugs (with special care of possible side effects).

The question is whether you want perl + its core modules to be stable in MacPorts (meaning remain with the latest perl 5.8.x and the core modules distributed with it) or choose new versions as soon as they are released (or well tested[*], which is the case of perl 5.10).

[*] This wasn't the case of perl 5.10.0 when it was released; that's why that was a testing release. But this was 9 months ago, and since then, there has been 9 months of testing.

[jmr@…]

I don't like that perl5 is just a clone of perl5.8; they conflict and there are ports that depend on both. Couldn't perl5 install nothing but a ${prefix}/bin/perl symlink, and depend on whichever perl5.x we decide is preferred?

[raimue@…]

The p5-* module ports already work with both versions of perl, they just need a correct ${prefix}/bin/perl symlink. But you can't install modules for both versions at the same time.

Do you want perl5 with +perl5.8 and +perl5.10 variants which add dependencies and create symlinks? Or create a perl_select package as we have for python now?

We should agree on one method (*_select or variants) and use it for all ports for which we provide multiple versions (python, ruby, perl).

[jmr@…]

Just as long as the conflict between perl5.8 and perl5 is fixed ASAP I'll be happy. I can't upgrade autoconf because I have perl5.8 installed, for example.

[jmr@…]

The problem with upgrading autoconf is actually that depspecs are auto-escaped, so variable substitution is not done, so it ends up looking for /opt/local/\${prefix}/bin/perl (because the prefix is prepended to any path that doesn't start with a slash.)

[vinc17@…]

Replying to raimue@…:

We should agree on one method (*_select or variants) and use it for all ports for which we provide multiple versions (python, ruby, perl).

But is there any reason to have multiple versions for perl? Why not simply upgrade to perl 5.10? (For instance, Debian did this.)

[mcalhoun@…]

Thanks for the autoconf fix.
I did not know the correct use of path dependency.
The incorrect form seems to be in other ports as well (including perl5-1.0.tcl).

Previously, I had not gotton any objections to the strategy in comment 5 ( http://trac.macports.org/ticket/16830#comment:5).
I was in the midst of implementing it.
If this is not a good idea, I can change course.

The basic strategy is:

• have perl5 be the main perl port.
• have perl5.8 and perl5.10 still exist but only for specialized needs.

In the long term, I think that this a reasonable strategy because after the initial pain, it will be easy to maintain without
perl_select, smylinks, or a plethora of p5- ports.

I fooled around with having perl5-1.0.tcl have +perl5, perl5.8, and +perl5.10 variants.
Perhaps it is my Tcl skills, but it was a difficult task (even with the python example).
In the end, it was ugly and didn't work with any p5- port which made use of ${perl5.lib} (e.g. p5-xml-sax).

To the objection that perl5.8 and perl5 are basically the same:
Upon the next MacPorts version release, perl5-1.0.tcl will be modified so that it no longer depends on perl5.8.
At that point perl5.8 could install to a different location just in case a user needs 5.8 (perl5 will eventually upgrade 5.10).

To the objection that perl5.10 should be used:
I was trying to make the transition from perl5.8 to perl5 as painless as possible.
At least one p5-* port breaks with perl5.10.
I did not know that Debian was using perl5.10, but Gentoo is still using 5.8.8.
I don't think it's a bad idea for perl5 to be the maintenance release, which is still 5.8.8.

[ryandesign@…]

Replying to mcalhoun@…:

Replying to jmr@…:

The problem with upgrading autoconf is actually that depspecs are auto-escaped, so variable substitution is not done, so it ends up looking for /opt/local/\${prefix}/bin/perl (because the prefix is prepended to any path that doesn't start with a slash.)

Thanks for the autoconf fix.
I did not know the correct use of path dependency.
The incorrect form seems to be in other ports as well (including perl5-1.0.tcl).

IMHO, the "incorrect form" that's currently in use in every other port is the correct form. That MacPorts is not handling it as documented is a bug that we should fix.

[vinc17@…]

Replying to mcalhoun@…:

To the objection that perl5.10 should be used:
I was trying to make the transition from perl5.8 to perl5 as painless as possible.
At least one p5-* port breaks with perl5.10.

Which one? Has a bug been reported against this port? Perhaps a fix is already available.

I don't think this is really a problem. Upgrades often introduce bugs, and this is not specific to perl. On the other hand, old bugs are also fixed.

I did not know that Debian was using perl5.10, but Gentoo is still using 5.8.8.
I don't think it's a bad idea for perl5 to be the maintenance release, which is still 5.8.8.

5.10.0 is the stable release and the 5.8 branch is no longer maintained. When 5.10.0 was released, it was in a testing status, but this was 10 months ago, and IMHO, this status now is out-of-date.

[blb@…]

If we go with perl5 being the primary port for perl, there needs to be some way to handle when its version changes since modules are installed in a version-specific subdir, eg (for p5-uri):

${prefix}/lib/perl5/vendor_perl/5.8.8/URI.pm

So if you upgrade perl5 (I did to 5.10.0 as a test), then try to use p5-uri (/Users/blb/MacPorts/mp-test being ${prefix} here):

$ ~/MacPorts/mp-test/bin/perl5 -e 'require URI;'
Can't locate URI.pm in @INC (@INC contains: /Users/blb/MacPorts/mp-test/lib/perl5/5.10.0/darwin-2level /Users/blb/MacPorts/mp-test/lib/perl5/5.10.0 /Users/blb/MacPorts/mp-test/lib/perl5/site_perl/5.10.0/darwin-2level /Users/blb/MacPorts/mp-test/lib/perl5/site_perl/5.10.0 /Users/blb/MacPorts/mp-test/lib/perl5/vendor_perl/5.10.0/darwin-2level /Users/blb/MacPorts/mp-test/lib/perl5/vendor_perl/5.10.0 /Users/blb/MacPorts/mp-test/lib/perl5/vendor_perl .) at -e line 1.

[mcalhoun@…]

When the PortGroup perl5 is updated to depend on perl5, then I believe this will happen automatically.
Each p5- port will depend on perl5, so when perl5 is upgraded, they will have to be upgraded as well into the correct directory.
Unless, of course, the user enters port -n upgrade perl5.

Am I characterizing the upgrade process correctly?

[blb@…]

A 'port upgrade' won't hit the modules if they appear to be the same version (eg, for p5-uri, 1.35_1). Since MacPorts doesn't have a way of saying 'this port needs to be rebuilt when a dependency is upgraded', the only way to force it would be to bump the revision. On all modules...

[mcalhoun@…]

When upgrading, I always use the uninstall option instead of the deactivate option.
As a result, I had forgotten what upgrade normally does.

Updating the reversion number of 614 p5- ports for every perl upgrade doesn't sound good.
Then there are the ports like graphviz which can install perl modules as well.

Drat.

Perhaps upon a perl5 upgrade (say 5.8.8 -> 5.10), post-activate can search through ${prefix}/lib/perl5/vendor_perl/5.8.8/,
find the ports which installed modules, then force a rebuild using system call to "port -f upgrade ${port}".

Assuming this idea even works, it's far from ideal, but, short of changing the MacPorts base, I can't think of anything else.

[blb@…]

Replying to mcalhoun@…:

Perhaps upon a perl5 upgrade (say 5.8.8 -> 5.10), post-activate can search through ${prefix}/lib/perl5/vendor_perl/5.8.8/,
find the ports which installed modules, then force a rebuild using system call to "port -f upgrade ${port}". Assuming this idea even works, it's far from ideal, but, short of changing the MacPorts base, I can't think of anything else.

What base could use is some sort of force_rebuild_dependents option in a port's Portfile, which would cause all dependent ports to be rebuilt when the given port is installed. There have been a few instances where this would be useful, but it is otherwise somewhat esoteric.

[dluke@…]

Replying to mcalhoun@…:

Perhaps upon a perl5 upgrade (say 5.8.8 -> 5.10), post-activate can search through ${prefix}/lib/perl5/vendor_perl/5.8.8/,
find the ports which installed modules, then force a rebuild using system call to "port -f upgrade ${port}".

This sort of thing has been suggested and tried before (for smoothing over port name changes, for instance) but there are some problems with running two instances of port simultaneously (and base/ wasn't designed for this - so it would probably take as much effort or more to make this work right as it would to make base/ support what needs to be done in a less hackish way).

[ryandesign@…]

Replying to jmr@…:

The problem with upgrading autoconf is actually that depspecs are auto-escaped, so variable substitution is not done, so it ends up looking for /opt/local/\${prefix}/bin/perl (because the prefix is prepended to any path that doesn't start with a slash.)

I filed a bug for this: #17182.

[mcalhoun@…]

Replying to blb@…:

What base could use is some sort of force_rebuild_dependents option in a port's Portfile, which would cause all dependent ports to be rebuilt when the given port is installed. There have been a few instances where this would be useful, but it is otherwise somewhat esoteric.

I have proposed something like that in #17473.

[jmr@…]

Replying to jmr@…:

I don't like that perl5 is just a clone of perl5.8; they conflict and there are ports that depend on both. Couldn't perl5 install nothing but a ${prefix}/bin/perl symlink, and depend on whichever perl5.x we decide is preferred?

From the number of tickets being filed because of the conflict, it looks like this would be saving a lot of user pain. Is there any reason for not doing it this way? (I don't see one given in the comments.)

[mcalhoun@…]

Replying to jmr@…:

Replying to jmr@…:

I don't like that perl5 is just a clone of perl5.8; they conflict and there are ports that depend on both. Couldn't perl5 install nothing but a ${prefix}/bin/perl symlink, and depend on whichever perl5.x we decide is preferred?

From the number of tickets being filed because of the conflict, it looks like this would be saving a lot of user pain. Is there any reason for not doing it this way? (I don't see one given in the comments.)

A little of the user pain was caused by #17182.
Most of the user pain, however, has been caused by a lack of foresight on my part.
If the dependency tree of large_port has, at some point, dependencies on path:bin/perl:perl5.8 and path:bin/perl:perl5, then

port install perl5.8 && port install large_port (no problem)
port install perl5 && port install large_port (no problem)
port install large_port (problem)

Most ports have been moved to the form path:bin/perl:perl5, but PortGroup perl5 can not be until the next version of MacPorts is released (it has been changed in r42484 and r42584).
Unfortunately, reports of this problem did not start coming in until after most ports had been changed to path:bin/perl:perl5.
Fortunately, almost all of them will stop as soon as the next MacPorts is released.

Couldn't perl5 install nothing but a ${prefix}/bin/perl symlink, and depend on whichever perl5.x we decide is preferred?

I think that transition would be even more difficult.
Simultaneously, we would have to change perl5.8 to not install ${prefix}/bin/perl and increase the revision number of all ports which expect ${prefix}/bin/perl to be provided by perl5.8.

Despite the problems, I still think this transition has been well worth it.
Previously, most ports depended on port:perl5.8 and expected it to provide ${prefix}/bin/perl, so an upgrade to Perl 5.10 still would have required many port changes.
We have also avoided the fate of python, where each port must take into consideration 2 to 4 different versions of python.

Just to reiterate, the long term goal is that, once we have the ability to force users to upgrade dependencies (see #17473), then we can

• Change perl5.8 so that it doesn't conflict with perl5 (and doesn't provide ${prefix}/bin/perl)
• Force users to upgrade all ports which depend on perl5.8.
• Live happily ever after (at least until Perl 6 comes out).

[mcalhoun@…]

Due to the continuing conflict between perl5 and perl5.8, I made perl5 into a placeholder port which depends on perl5.8 (r43286).
When the next MacPorts is released and all the p5- port start depending on perl5, perhaps then would be a good time to change it back.

[jason@…]

Replying to mcalhoun@…:

Due to the continuing conflict between perl5 and perl5.8, I made perl5 into a placeholder port which depends on perl5.8 (r43286).
When the next MacPorts is released and all the p5- port start depending on perl5, perhaps then would be a good time to change it back.

Something isn't working correctly now. These are the perl executables in my bin folder:

-rwxr-xr-x  2 root  admin  1147556 Dec 23 06:29 perl
-rwxr-xr-x  1 root  admin  1147556 Nov 20 16:05 perl.mp_1227218499
-rwxr-xr-x  1 root  admin  1147556 Nov 20 20:15 perl.mp_1227230449
lrwxr-xr-x  1 root  admin        9 Dec 23 06:31 perl5 -> perl5.8.8
lrwxr-xr-x  1 root  admin       24 Dec 23 06:31 perl5.8 -> /opt/local/bin/perl5.8.8
-rwxr-xr-x  2 root  admin  1147556 Dec 23 06:29 perl5.8.8
-rwxr-xr-x  1 root  admin  1147556 Nov 20 16:05 perl5.8.8.mp_1227218499
-rwxr-xr-x  1 root  admin  1147556 Nov 20 20:15 perl5.8.8.mp_1227230449

So you can see the problem is perl5 and perl5.8 now just point to each other. So if something tries to execute either one, a failure occurs. I tried forcing and uninstall of perl5 and perl5.8 & reinstalling just to be sure this is the current behavior.

[jason@…]

Sorry, directory structure didn't format correctly:

-rwxr-xr-x  2 root  admin  1147556 Dec 23 06:29 perl
-rwxr-xr-x  1 root  admin  1147556 Nov 20 16:05 perl.mp_1227218499
-rwxr-xr-x  1 root  admin  1147556 Nov 20 20:15 perl.mp_1227230449
-lrwxr-xr-x  1 root  admin        9 Dec 23 06:31 perl5 -> perl5.8.8
-lrwxr-xr-x  1 root  admin       24 Dec 23 06:31 perl5.8 -> /opt/local/bin/perl5.8.8
-rwxr-xr-x  2 root  admin  1147556 Dec 23 06:29 perl5.8.8
-rwxr-xr-x  1 root  admin  1147556 Nov 20 16:05 perl5.8.8.mp_1227218499
-rwxr-xr-x  1 root  admin  1147556 Nov 20 20:15 perl5.8.8.mp_1227230449

Replying to jason@…:

Replying to mcalhoun@…:

Due to the continuing conflict between perl5 and perl5.8, I made perl5 into a placeholder port which depends on perl5.8 (r43286).
When the next MacPorts is released and all the p5- port start depending on perl5, perhaps then would be a good time to change it back.

Something isn't working correctly now. These are the perl executables in my bin folder: -rwxr-xr-x 2 root admin 1147556 Dec 23 06:29 perl -rwxr-xr-x 1 root admin 1147556 Nov 20 16:05 perl.mp_1227218499 -rwxr-xr-x 1 root admin 1147556 Nov 20 20:15 perl.mp_1227230449 lrwxr-xr-x 1 root admin 9 Dec 23 06:31 perl5 -> perl5.8.8 lrwxr-xr-x 1 root admin 24 Dec 23 06:31 perl5.8 -> /opt/local/bin/perl5.8.8 -rwxr-xr-x 2 root admin 1147556 Dec 23 06:29 perl5.8.8 -rwxr-xr-x 1 root admin 1147556 Nov 20 16:05 perl5.8.8.mp_1227218499 -rwxr-xr-x 1 root admin 1147556 Nov 20 20:15 perl5.8.8.mp_1227230449 So you can see the problem is perl5 and perl5.8 now just point to each other. So if something tries to execute either one, a failure occurs. I tried forcing and uninstall of perl5 and perl5.8 & reinstalling just to be sure this is the current behavior.

[jason@…]

Cc Me!

[jason@…]

Cc Me!

[jason@…]

Cc Me!

[mcalhoun@…]

Replying to jason@…:

So you can see the problem is perl5 and perl5.8 now just point to each other. So if something tries to execute either one, a failure occurs. I tried forcing and uninstall of perl5 and perl5.8 & reinstalling just to be sure this is the current behavior.

From what I can see, perl5 and perl5.8 both point to perl5.8.8, which is an executable.
Why is this not correct?

On my machine,

/opt/local/bin/perl5 --version
/opt/local/bin/perl5.8 --version
/opt/local/bin/perl5.8.8 --version

all run.

What is the failure?

[ryandesign@…]

Replying to jason@…:

Sorry, directory structure didn't format correctly

You need to use WikiFormatting. :)

[mcalhoun@…]

I believe that all perl5.8 dependencies have been removed except from those ports that want it.

The following ports depend on perl5.8 but ensure that the perl binary is ${prefix}/bin/perl5.8: lang/ghc security/libpreludedb sysutils/rpm-devel sysutils/rpm sysutils/rpm45 sysutils/rpm50 sysutils/rpm51 sysutils/rsnapshot

[tommyd@…]

Cc Me!

[dreamind@…]

Cc Me!

[mechanic@…]

It seems everything is in place now. What's the current roadmap?

[mcalhoun@…]

perl5 was initially created to be the latest maintenance release of perl, which is still 5.8.9 until 5.10.1 is released.
So the plan at this point is to

• Wait until 5.10.1 is out.
• Change perl5.8 so it does not conflict.
• Have perl5 install software instead of being a stub package.

[anonymous]

Milestone Port Enhancements deleted

[protsman@…]

Cc Me!

[protsman@…]

Cc Me!

[ricci@…]

For the 'default-perl-5.10.diff' patch added, I don't like the idea of having perl5.10 search perl5.8.x module paths - especially for those that are compiled - I'd fully expect them to break. Do we have a way to make all perl modules rebuild on a change to this port (I think no...)?

[mechanic@…]

Perl version 5.10.1 has been officially released.

[ryandesign@…]

Replying to ricci@…:

Do we have a way to make all perl modules rebuild on a change to this port (I think no...)?

Only by increasing the revision of all perl modules.

[vinc17@…]

Otherwise, perhaps a script could be provided to force-remove all installed perl modules and rebuild them (with the drawback that one can't revert to the previous version/revision in case of problem).

[dluke@…]

Note that it's pretty easy to do this yourself even if there's not a script provided.

I've been doing something like the following since back in the darwinports days:

$ port installed | grep p5 | cut -f 3 -d " " > perl_ports.txt
$ foreach i (`cat perl_ports.txt`)
foreach -> sudo port -d -v -f uninstall $i
foreach -> sudo port -d -v -f clean --archive $i
foreach -> end

...

$ foreach i (`cat perl_ports.txt`)
foreach -> sudo port -d -v install $i
foreach -> end

[dluke@…]

WikiFormatting ...

Replying to dluke@…:

Note that it's pretty easy to do this yourself even if there's not a script provided. I've been doing something like the following since back in the darwinports days:

$ port installed | grep p5 | cut -f 3 -d " " > perl_ports.txt
$ foreach i (`cat perl_ports.txt`)
foreach -> sudo port -d -v -f uninstall $i
foreach -> sudo port -d -v -f clean --archive $i
foreach -> end
 
...
 
$ foreach i (`cat perl_ports.txt`)
foreach -> sudo port -d -v install $i
foreach -> end

[jmr@…]

Replying to ricci@…:

For the 'default-perl-5.10.diff' patch added, I don't like the idea of having perl5.10 search perl5.8.x module paths - especially for those that are compiled - I'd fully expect them to break. Do we have a way to make all perl modules rebuild on a change to this port (I think no...)?

You'll notice that the patch deliberately doesn't include the 5.8.*/${os.platform}*-2level paths, which I believe is where all the C modules go? Theoretically, pure perl modules should just work (and I haven't noticed any failures so far). So everything compiled would need a rev bump, but not the rest.

[takashi@…]

Cc Me!

[jmr@…]

updated patch

[jpo@…]

Cc Me!

[jabronson@…]

Cc Me!

[skaimauve@…]

There is a problem with the uninstall/clean/install script above, as it uninstall all php5* ports.

And if the loop does not quite work for you can try:

$port installed | grep p5 | grep -v php5 |  cut -f 3 -d " " > perl_ports.txt
$cat perl_ports.txt | xargs sudo port -d -v -f uninstall
$cat perl_ports.txt | xargs sudo port -d -v -f clean --archive
$cat perl_ports.txt | xargs sudo port -d -v install

[ryandesign@…]

Replying to skaimauve@…:

There is a problem with the uninstall/clean/install script above, as it uninstall all php5* ports.

Oops! :)

port installed | grep p5 | grep -v php5 | cut -f 3 -d " " > perl_ports.txt

Or better yet:

port installed name:^p5- | cut -f 3 -d " " > perl_ports.txt

[ematiu@…]

Cc Me!

[ematiu@…]

mod_perl patch for perl5.10

[ematiu@…]

Attached is a small patch for building mod_perl2 with perl5.10 as the default perl version.

[mjg@…]

Cc Me!

[Markus.Ueberall@…]

Cc Me!

[reg-macports.org@…]

I'd like to note that Snow Leopard comes with perl 5.10:

$ /usr/bin/perl --version

This is perl, v5.10.0 built for darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)

It seems odd that MacPorts by default installs an older perl than the one that comes with the operating system.

[vinc17@…]

Especially now since 5.10.1 is in the maint branch.

[tomas.znamenacek@…]

Cc Me!

[ricci@…]

patch for perl5 Portfile to clean it up, default to perl5.8, variant perl5_10 for perl5.10

[ricci@…]

Committed attachment 'perl5.Portfile.diff' in r62843.

[steve@…]

Cc Me!

[sorin.sbarnea@…]

Cc Me!

[sorin.sbarnea@…]

Installing an older perl release that does not support multi-threading is a serious issue on 10.6.

[ricci@…]

Replying to sorin.sbarnea@…:

Installing an older perl release that does not support multi-threading is a serious issue on 10.6.

That's a pretty vague and unhelpful comment. You could equally say that walking across the street is a serious issue (after all, there are multi-thousand pound mechanical devices in the street, moving faster than you can run!). If you've got particular reasons to think the above, please indicate what they are, and if you really want to do it well, also indicate what tradeoffs are involved.

In the meantime, you can install:

perl5.10 +threads

perl5 +perl5_10

and you should have what you appear to want.

If you really want to be helpful, you can help determine the best way to flip the perl5 port to default to installing perl5.10 *and* make sure that all the ports that are already installed are either upgraded or continue to work.

[ricci@…]

resolved in r76485