Perl 5.8.8 already present on Leopard; can I make a "dummy" Portfile?

[Ryan Schmidt]

On Dec 29, 2008, at 00:45, nicerobot wrote:

> I fully understand the design decision. My point is that the  
> decision is
> flawed because it's too inflexible. Macports should be more  
> versatile with
> respect to perl because perl modules aren't generally treated the  
> same as
> binary libraries (i.e. the FAQ link you referenced isn't completely
> applicable to perl modules). It's completely acceptable and  
> understandable
> for macports to provide it's own version(s) of perl and even to  
> require a
> set of modules. There's just absolutely no reason whatsoever that  
> macport's
> version of perl can't, for those that decide to do so, share/ 
> combine the
> @INC with the OS's perl's @INC, especially when the two builds of  
> perl are
> identical versions.

That's just it -- the version of Perl included with Mac OS X and the  
version of perl5.8 in MacPorts happen to be identical at this moment  
in time -- they're both 5.8.8. But Perl 5.8.9 was released two weeks  
ago, and the perl5.8 port will likely be updated to that version  
soon. Then they are different versions. Based on past experience, I  
would guess Apple will never update the version of Perl provided in  
Panther (because they're not updating anything for Panther anymore),  
and they'll probably only update the versions in Tiger and Leopard if  
the new version fixes a security issue or some other show-stopper,  
and even then they may not do so for months. This is the whole reason  
we want MacPorts to use software provided by MacPorts, and not  
software provided by Apple in Mac OS X -- so that we're not stuck to  
whatever release schedule Apple decides to use.

We also routinely have trouble when users have already installed  
software in /usr/local and then start using MacPorts -- lots of  
software in MacPorts looks in /usr/local first and if it finds what  
it's looking for, uses that version of the software instead of the  
copy MacPorts installed, and then things often don't work right  
because the version in /usr/local is older than what we need.

The point, as others have made, is that things work best when you let  
MacPorts manage all your software for you.