perl5.8 fixup

Eric Hall opendarwin.org at darkart.com
Fri Mar 6 09:26:45 PST 2009


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


			-eric



More information about the macports-dev mailing list