#17803: RFE: upgrade perl5.8 5.8.8 -> 5.8.9 ------------------------------------+--------------------------------------- Reporter: mcalhoun@… | Owner: ricci@… Type: enhancement | Status: reopened Priority: Normal | Milestone: Port Updates Component: ports | Version: 1.7.0 Resolution: | Keywords: Port: perl5.8 | ------------------------------------+--------------------------------------- Comment(by ricci@…): Replying to [comment:4 mcalhoun@…]:
Replying to [comment:2 ricci@…]:
I just installed perl 5.8.9 via the updated port and checked the
@INC path (both via "/opt/local/bin/perl -V" and via the above script) and it does not pull in the 5.8.8 paths (as expected, its version 5.8.9, not version 5.8.8). Also tested by 'use'ing p5-locale-gettext (which I have installed from perl5.8 @5.8.8), perl5.8 @5.8.9 fails to find it (again, as expected). Did your test pick up the (old) perl 5.8.8 instead of perl 5.8.9?
The Configure script searches "previous versions to include in @INC."[[BR]] It correctly found 5.8.8 on my machine when I used "port upgrade perl5.8,"[[BR]] From the previous comment, it apparently worked for others as well.
The question is how this will impact users - I think if they
uninstall their perl modules and rebuild them they'll be fine, otherwise they'll have ports that are registered as installed but are not available to the active perl binary. If, on some machines, the Configure script fails to find old versions, then it can be explicitly set during the call to the Configure script.[[BR]] Since I can not reproduce the problem, does the output during your installation offer any clue?
Mine did not pick up the existing 5.8.8 install (List of earlier versions to include in @INC? [none] - checking my history I believe I still had 5.8.8 installed and active when I did the build of 5.8.9. I did not use 'port upgrade', I used 'port build', then 'port deactivate perl5.8', then 'port install' to do the upgrade. I don't see why that would behave differently in terms of picking up the 5.8.8 install unless I did the deactivation first (which is not what my history shows). While we could add something to the configure phase to pick up the 5.8.8 dirs for @INC, I think it'd be better to not use 5.8.8 dirs so we avoid compiled modules. I'm on 10.5.6 x86, dunno why OS/arch differences would matter though. -- Ticket URL: <http://trac.macports.org/ticket/17803#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS