[112798] trunk/dports/archivers/upx/Portfile

[Ryan Schmidt]

On Nov 1, 2013, at 15:59, Jeremy Lavergne <jeremy at lavergne.gotdns.org> wrote:

>> If we remove the perl5 port and switch to users using “port select” to create the /opt/local/bin/perl symlink, then we cannot from any other port rely on /opt/local/bin/perl existing, just like we cannot from any other port rely on anything else that “port select” creates for any other port.
> 
> That sounds like complete defeat to me: not one of our mechanisms will work.
> 
> What’s the point of _anything_ we’re doing with perl?

Well the reason why we have perl is to let users install perl. And we have perl modules so that users who want to use them can install them, and so that ports that need them can depend on them.

Some years ago we switched to offering multiple versions of perl, and corresponding multiple perl versions of the modules, so that users or ports that needed a specific version could have it. (This desire was the reason why the subport feature of MacPorts was created.) For example there was a time after we made 5.12 the default perl where ghc still required perl 5.8. That problem has since been resolved.

Today, if a port needs a perl module, it must depend on a specific perl version of that module; typically the perl 5.12 version is used because that’s the default variant of the perl5 port. The port’s build system must also be told to use that specific perl, e.g. via a configure arg, build env, or patchfile.

Breaking our perl and perl module ports out by perl version has an advantage: if we did not do this, then upgrading the perl5 port to a new major version would involve revbumping all module ports (because the perl version number is in the directory name into which the modules are installed) which would be tedious since there are over 1000 of them, though not impossible.