> 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`.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
