On Jul 4, 2013, at 1:30 AM, Joshua Root <[email protected]> wrote: > On 2013-7-4 18:04 , Jeremy Huddleston Sequoia wrote: >> >> On Jul 3, 2013, at 11:57 PM, Joshua Root <[email protected]> wrote: >> >>> Changing the perl used by intltool doesn't fix anything by itself, it >>> just shifts the problem from "setting perl5 to anything but 5.12 causes >>> problems" to "setting perl5 to anything but 5.16 causes problems”. >> >> Eh... not really... it shifts it to “having perl5 and intltool not match >> variants causes problems” which is much less likely. Hell, I’d be in >> support of just saying that you can’t switch +perl variants like we say you >> can’t toggle +universal. Then we could just remove all the fuss in the >> other Portfiles. > > Well, intltool didn't have perl variants before, and doesn't really need > them any more than any other port that uses perl modules. Last time the > topic was discussed we decided to just use the current default perl > version in such cases.
Personally, I’d prefer a perlvariants PortGroup (and one for python too) to handle these variants. That being said, I’m not that dead set on that, but there is specific benefit from having the variant in intltool (because of that braindead autoconf macro). If the group decides that it’s ok to just require that intltool and perl5 always match variant, that would be the best solution as then we’d need to do *nothing* in ports that depend on intltool. In the mean time, I’ll keep fixing up the existing setting of INTLTOOL_PERL in the environment as I hit them > Or if the relevant maintainers want to remove the old perl versions or > just have one version, that's fine with me. I don't even use perl > directly most of the time. Yeah, I think my only real use for it at this point is ack ... but I just don’t like things being messy like this =)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
