multiple perl versions
Jeremy Lavergne
jeremy at lavergne.gotdns.org
Wed Feb 15 19:39:44 PST 2012
> I don't doubt that there are some benefits to supporting multiple
> simultaneous perl installations. But doing so imposes a substantial
> burden on maintainers of ports that use perl, in terms of
> maintainability and reliability: they need to be careful about which
> version of perl they're depending on and invoking, and non-default
> configurations probably aren't tested often.
>
> In fact, what we have now may be the worst possible world: we claim to
> support multiple perl versions, and ports have to go to some effort to
> specify which version they depend on, but it doesn't even work -- the
> p5.x- perl module ports conflict with each other!
>
> To give a few examples of the sort of problems this causes:
>
> - gnucash depends on p5.12-finance-quote (and its many dependencies).
> But autoconf detects that /opt/local/bin/perl is available, and so
> some of its scripts (e.g. gnc-fq-check) use that. This won't work
> right if perl5 +perl5_14 is installed.
>
> - even the scripts installed by the perl5.x ports themselves have
> this problem. For example, on my system, `cpan-5.14` invokes perl
> 5.12. That seems unexpected.
>
> - intltool depends on various p5.12 modules. Unfortunately, most
> packages using intltool try to invoke it using /opt/local/bin/perl,
> causing it to fail if that's not perl5.12. See, for example, #32425.
> Unfortunately, this needs to be fixed by setting INTLTOOL_PERL in
> every port that *uses* intltool. Most of the ~200 such ports don't
> do this.
>
> It isn't that any of these problems, individually, are particularly
> hard to solve -- but they seem sufficiently widespread that it makes me
> question whether supporting multiple perl versions is worth it.
>
> I can't think of any other distribution that tries to do this.
Those examples should definitely sting.
We can definitely move ahead with just one perl and then retool the system and THEN begin offering multiple perls. It would be easier than simply fixing what we have now.
More information about the macports-dev
mailing list