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

[Jeremy Lavergne]

I clearly misunderstood your last comment on the ticket:

> Some time has passed, and subports now solve this part of the problem. Are there any remaining reasons why we should not remove the perl5 port and add the perl_select port as suggested? We would of course need to find all ports depending on the perl5 port and change them to depend on a specific perl port.

It sounds like we can’t and shouldn't remove dependencies on perl5.

But we can’t rely on port:perl5 because there’s no real variant enforcement going on. Doesn’t requesting perl5 with one variant then again with a different variant effectively switch it out from under a port just like port select would?

What should be happening then?

On Nov 1, 2013, at 16:33, Ryan Schmidt <ryandesign at macports.org> wrote:

> Well, this is the reason I haven’t touched it. It was convenient to have a port providing “perl”, “pod2man”, etc. The “port select” mechanism is what we decided we wanted to use, but that it was for a user’s convenience, and that ports cannot rely on a user having chosen any particular version. Lots of configure scripts and build systems will try to use “perl”, “pod2man”, etc. If we switch perl to use “port select” and get rid of the perl5 port’s symlinks to MacPorts versions of those, then those build systems will fall back to using the OS X versions of those programs. That might be fine. If not — if a program requires a newer perl — then the dependency can be updated and the build system patched.