perl5.8 fixup

[Bradley Giesbrecht]

On Mar 6, 2009, at 9:26 AM, Eric Hall wrote:

> On Fri, Mar 06, 2009 at 01:53:39AM +0000, Marcus Calhoun-Lopez wrote:
>> Eric Hall <opendarwin.org at ...> writes:
> [snip]
>
>>> 	Overall I agree there is a problem with the way that
>>> perl (at least perl5.8) and modules (p5-*) currently interact, and
>>> we need a good (great? sufficient?) solution for the problem.
>>>
>>
>> What about the following:
>>    * Do not overwrite any perl modules (no more -f)
>>           and have the perl5.8 modules found first (don't invert  
>> @INC).
>>    * If the module supplied by perl is sufficient, do not add it as  
>> a dependency.
>>    * If  a newer version of the module is needed, patch the port
>>              use xxx; ->   use lib 'dir_location';
>>                                      use xxx;
>>                                      @INC = @lib::ORIG_INC;
>>       lib prepends dir_location to INC (see http://perldoc.perl.org/lib.html) 
>> .
>>    * Append the version number to the man pages of conflicting p5-*  
>> ports
>>           so they no longer conflict.
>>       They will not be found by default, but neither will the perl  
>> modules.
>>
>> This assumes the number of ports which actually need the newer  
>> version
>> is relatively small, so there would not be much patching involved.
>>
>> The advantages:
>>   - No more -f
>>   - Since @INC is not modified, invoking ${prefix}/bin/perl will be  
>> the same
>>          no matter if a newer p5-* port is installed or not.
>>
>
> 	Have you tested the above idea?  I think I've seen cases
> where that will fail, unfortunately its been long enough that I
> don't remember the exact particulars.  The basic problem is:
> 	There are scripts and/or modules that require a certain
> minimum version of module X, but the (initial?) inclusion of the  
> module X
> is made in some other module, thus patching the one that requires
> the particular version doesn't have effect, or there was some sort
> of collision between two versions of the same module.
> 	Sorry I don't remember the exact case, we'd have to test it
> out with both pure-perl modules and xs modules.
>
> 	Ah, another case where that can fail is if module Y requires
> module X at a particular version.  If a calling script already  
> imported
> module X (at a lower-than-required version), I don't think module Y
> will re-import the "right" version.  Again, we should test to make
> sure that I've got it right (and/or to see if that's old behavior
> that has been changed/fixed).
>
>
> 	So far as appending the version number to the man pages, that
> seems like a reasonable way to avoid the man page file collision,  
> though
> as you point out it still results in the man pages not being found.
> The other option is to do what perl5.10 does, and append the perl
> version number to the man pages installed by the perl5.8 port and
> not alter the filenames of the man pages installed by the p5-* ports.
> 	If we're going to alter the filenames, I like appending the
> perl version number as it makes things more consistent, people only  
> have
> to learn one pattern to get the man pages (vs.  finding the version
> number of every p5-* port that is installed and appending that  
> particular
> version string to the man page request).


How about creating a Portfile for ALL the perl5.8 modules, make them  
all depends of perl5.8, unregistering them from perl5.8 and  
registering the module on there own.
Then those p5 modules that existed before can replace the ones created  
from the perl5.8 base modules with a higher revision number.

Then a port upgrade installed should work to upgrade all the p5  
modules with newer versions that have been added.

//Brad