perl5.8 fixup

Eric Hall opendarwin.org at darkart.com
Mon Mar 9 14:25:45 PDT 2009


On Sun, Mar 08, 2009 at 02:41:50AM +0000, Marcus Calhoun-Lopez wrote:
> Bradley Giesbrecht <brad at ...> writes:
> 
> Thank you for the clarification.
> 
> > > If I understand what is being discussed (please correct me if I'm  
> > > wrong),
> > > we would
> > >   * copy perl5.8 -> perl5.8-core.
> > >   * create a port which installs all the core p5 ports.
> > >   * make perl5.8 do nothing except depend on perl5.8-core and the  
> > > new p5 umbrella port.
> > >
> > > It seems that this does not buy us anything, so I fear I am missing  
> > > something.
> > 
> > It buys us perl modules as p5 ports that used to be part of perl5.
> > This allows us to update those p5 ports to newer required versions  
> > without having to have a perl5 revision increment and upgrade perl5.
> 
> It seems it would only do that if the @INC variable were modified
> or conflicting modules pruned from perl5.8.
> 
> I would suggest that these goals could be accomplished more easily
> by the following (sorry for the duplication from an earlier message):
>   * Modify @INC so the newer p5 ports are found first.
>   * Do not add conflicting p5 port as dependencies unless the newer version is
>          actually required (mitigate the potential problems).
>   * Prepend p5- to the conflicting man pages.
>   * Modify the -f p5 ports so they no longer install in the directory
> perl reserves for itself.
> 
> This would require a minor change to perl5.8, a few minor
> changes to "-f" p5 ports and some cleanup to minimize dependencies.

	I too think that modifying @INC is a better (no, much, much
better) solution to the problem of "I want to install a newer
version of perl module XYZ".  Is there any reason to *not*
modify @INC for perl5.8 (and presumably perl5.10) by inverting
the search to find vendor_perl first, then site_perl, then
${PERL_VERSION} (aka the core modules)?

	So far as the man pages go, I'm not understanding what
the 'Prepend p5- to the conflicting man pages.' really means -
prepend 'p5-' to the base (perl5.x) installed pages, or to
the pages installed by the p5-* ports?
	I'd prefer something like what the perl5.10 port does -
alter the man pages installed by the core perl port rather
than have each module's port alter its man pages (are there
conflicts there too??).

	I'd also like to look at -Dman1direxp, -Dman3direxp,
-Dsiteman1direxp, -Dsiteman3direxp, -Dvendorman1direxp, and
-Dvendorman3direxp to see if that will provide a functional
(and reasonably expected) solution for the man page
collision problem.


	Otherwise I agree with the four steps outlined above
(modify @INC, don't add conflicting p5-* ports as deps unless
needed, (do something to avoid man page conflicts), and
modify the '-f p5-*' ports so they no longer install into
the base/core perl directories).



	I think removing the core perl modules from the perl5.x
port and making them installed by a perl5.x-modules "meta" port
is a very bad idea.  Then there is no way to use the original
core perl modules alongside the updated perl modules,
if that is somehow desired/required (its fairly easy to do
if both versions of a module are installed and one is willing
to tweak one's script or module to pick the right one - something
we do not want to be doing at a general level, but a knowledgable
user could still do if they wanted).




			-eric




More information about the macports-dev mailing list