Updating php56-apache2handler gives configure error

Ryan Schmidt ryandesign at macports.org
Mon Nov 2 17:06:36 PST 2015


On Nov 2, 2015, at 9:28 AM, Brandon Allbery wrote:
> 
> On Mon, Nov 2, 2015 at 10:26 AM, Murray Eisenberg wrote:
> 
>> Hm. Sounds like a dangling link to a no longer installed perl --- but that's something that "port select" can cause but the perl5 port shouldn't. Confusing.
> 
> Unless I'm misunderstanding something, "port select" does not work at all for perl:
> 
> It doesn't.

That's correct. That bug is:

https://trac.macports.org/ticket/29763

It is not an easy bug to fix because the select mechanism is defined to be something for the user to use, but we have zillions of ports relying on the perl symlink the perl5 port installs. One solution might be to change all ports that currently depend on that perl symlink so that they depend on a specific version of perl instead, but that's a lot of work, and work that would want to be repeated every time we declare that a new version of perl shall be the default version, so that isn't great. It's been suggested that this and other issues would be avoided by abandoning the idea of offering multiple versions of perl and going back to a single version of perl, like we had years ago.


> But one of the shortcomings of the "port select" mechanism in general is that there are circumstances where it leaves dangling symlinks around;

That bug is:

https://trac.macports.org/ticket/47755


> the variants-based mechanism used by the perl ports can't normally do this, unless you've been playing games with --force or manually removing stuff. So I'm confused as to how you managed to have an invalid /opt/local/bin/perl.

Evidently Murray forcibly deactivated his perl5 port, or something went wrong in MacPorts that caused it to become deactivated. The solution would be to reactivate the desired version/variant of the perl5 port.




More information about the macports-users mailing list