port select perl

Jeremy Lavergne jeremy at lavergne.gotdns.org
Thu Feb 21 09:37:29 PST 2013

> I've used the same (or equivalent) facilities in Fedora;
> It certainly can be part of the solution,
> but it seems that the current setup is only implementing
> half the solution.

Agreed, and we should further discuss a viable framework so work can be done for changes to perl installs.

Multiple versions of languages installed by package managers that then provide their own package managers... likely why things end up being a mess in the end.

The only safe way around this is a "works for any version" source directory (site_perl?) and a per-version (vendor_perl?) directory. Assuming that's what they're even meant to be used for (do we have any authoritative perl-ers around?), then everything has to be in agreement for it to work. Since we're only halfway there... well we all know the current story! And I'll save my perl jokes for another day ;-)

> But perhaps software packagers should consciously
> choose whether there software is going to be setup
> with alternatives;  Otherwise I'm not sure how you
> get alternative-aware Portfile setups to cooperate
> with traditional Makefile or CPAN installations.

Usually it's just a matter of letting MacPorts update configure.args/build.args to set the right paths for use in a given Portfile. PortGroups (effectively includes) provide these changes that should impact multiple Portfiles, so it should be a seamless change except for maintainers who clobber settings in their Portfiles (`configure.args` instead of `configure.args-append`) or dont' make use of the PortGroup.

Same goes for updating shebang lines on all installed scripts: it should be pointing to the specific version that installed it e.g. `${prefix}/bin/python2.7` not just `python`.

More information about the macports-dev mailing list