Opened 12 years ago

Closed 12 years ago

Last modified 4 years ago

#17803 closed update (fixed)

RFE: upgrade perl5.8 5.8.8 -> 5.8.9

Reported by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) Owned by: ghosthound
Priority: Normal Milestone:
Component: ports Version: 1.7.0
Keywords: Cc: calle.kabo@…, dbevans (David B. Evans), dershow
Port: perl5.8

Description

Attached is a proposed update to perl5.8.
Most of the patches are no longer needed.

After I upgraded,

/opt/local/bin/perl -e 'print join "\n", @INC'

showed that the 5.8.8 directories were still searched
(so no revision increase of the p5-* ports would be needed).
Can this be confirmed?

Attachments (1)

Portfile.diff (3.1 KB) - added by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) 12 years ago.

Download all attachments as: .zip

Change History (18)

Changed 12 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Attachment: Portfile.diff added

comment:1 Changed 12 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: newclosed

Fixed in r44874.

comment:2 in reply to:  description ; Changed 12 years ago by ghosthound

Resolution: fixed
Status: closedreopened

Replying to mcalhoun@…:

Attached is a proposed update to perl5.8.
Most of the patches are no longer needed.

After I upgraded,

/opt/local/bin/perl -e 'print join "\n", @INC'

showed that the 5.8.8 directories were still searched
(so no revision increase of the p5-* ports would be needed).
Can this be confirmed?

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

comment:3 Changed 12 years ago by skymoo (Adam Mercer)

Works for me:

[ram@cizin ~]$ /opt/local/bin/perl -e 'print join "\n", @INC, ""'
/opt/local/lib/perl5/5.8.9/darwin-2level
/opt/local/lib/perl5/5.8.9
/opt/local/lib/perl5/site_perl/5.8.9/darwin-2level
/opt/local/lib/perl5/site_perl/5.8.9
/opt/local/lib/perl5/site_perl/5.8.8/darwin-2level
/opt/local/lib/perl5/site_perl/5.8.8
/opt/local/lib/perl5/site_perl
/opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level
/opt/local/lib/perl5/vendor_perl/5.8.9
/opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level
/opt/local/lib/perl5/vendor_perl/5.8.8
/opt/local/lib/perl5/vendor_perl
.
[ram@cizin ~]$

comment:4 in reply to:  2 ; Changed 12 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Replying to 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."
It correctly found 5.8.8 on my machine when I used "port upgrade perl5.8,"
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.
Since I can not reproduce the problem, does the output during your installation offer any clue?

comment:5 Changed 12 years ago by dbevans (David B. Evans)

Cc: calle.kabo@… added

Works for me as well (same results as ram above) but #17884 may be a case to the contrary. It appears to be a case where perl has been upgraded to 5.8.9, port reports p5-xml-parser to be installed but gimp2 configure fails to find XML::Parser using

/opt/local/bin/perl -e "require XML::Parser"

adding reporter of this ticket to cc for his information.

comment:6 in reply to:  4 Changed 12 years ago by ghosthound

Replying to mcalhoun@…:

Replying to 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."
It correctly found 5.8.8 on my machine when I used "port upgrade perl5.8,"
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.
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.

comment:7 Changed 12 years ago by ralph@…

See #17895. I upgraded perl to 5.8.9, and now my macports system DOES NOT consider the 5.8.8 dirs, resulting in XML::Parser being missing.

comment:8 Changed 12 years ago by dbevans (David B. Evans)

Cc: devans@… added

Cc Me!

comment:9 Changed 12 years ago by dershow

Cc: dersh@… added

Cc Me!

comment:10 Changed 12 years ago by dershow

I can confirm the same issue with both a 10.5.5 PPC machine and a 10.5.5 Intel machine, so I don't think that the hardware matters.

comment:11 Changed 12 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

r45042 is an attempt to fix this problem.
Please let me know if it works.

comment:12 Changed 12 years ago by dershow

Yes. Now I can update the other ports, although I did have to first do: sudo port upgrade perl5.8

then I did: sudo port upgrade outdated

But all seems fine to me now.

comment:13 Changed 12 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: reopenedclosed

comment:14 Changed 12 years ago by jmroot (Joshua Root)

Type: enhancementupdate

comment:15 Changed 12 years ago by (none)

Milestone: Port Updates

Milestone Port Updates deleted

comment:16 Changed 10 years ago by martin.osx@…

Great, got the same problem with GIMP now. And I can't even de-install perl — that stops dead with a “possible” recursion in dependencies. What a mess.

comment:17 Changed 4 years ago by larryv (Lawrence Velázquez)

#43480 removed the subrelease number from the library path.

Note: See TracTickets for help on using tickets.