Upgrading perl from 5.12 to 5.16?

[Ryan Schmidt]

On May 27, 2013, at 14:48, Johannes Kastl wrote:

>> Ok. You shouldn't have had to force-deactivate anything though.
>> Simply installing perl5 +perl5_16 on top of the existing perl5 port
>> should have caused MacPorts to deactivate the existing perl5 port
>> automatically.
> 
> Should. But did not. I'm sorry I did not note the error message.

Worked fine for me:

$ port installed perl5{,.12,.16}
The following ports are currently installed:
  perl5 @5.12.4_0+perl5_12 (active)
  perl5.12 @5.12.4_2+universal (active)
  perl5.16 @5.16.1_3+universal (active)
$ sudo port install perl5 +perl5_16
--->  Computing dependencies for perl5
--->  Fetching distfiles for perl5
--->  Verifying checksum(s) for perl5
--->  Extracting perl5
--->  Configuring perl5
--->  Building perl5
--->  Staging perl5 into destroot
--->  Installing perl5 @5.12.4_0+perl5_16
--->  Deactivating perl5 @5.12.4_0+perl5_12
--->  Activating perl5 @5.12.4_0+perl5_16
--->  Cleaning perl5
$

If that's not what happened for you, you could file a bug report.


>> You can install p5.12-image-exiftool and p5.16-image-exiftool
>> simultaneously, and in general any p5.X-Z and p5.Y-Z. If you no
>> longer want p5.12-image-exiftool and now want p5.16-image-exiftool,
>> uninstall the former and install the latter.
> 
> Of course I can. But why should I install everything in duplicate? If
> one is enough upgrade perl from 5.12 to 5.16 should replace
> p5.12-image-exiftool by p5.16-image-exiftool IMHO. At least that is
> what I would have assumed. But I am not an expert.
> 
>> On May 27, 2013, at 14:11, Johannes Kastl wrote:
>> 
>>> 3. How to get intltool to use p5.16 instead of 5.12 for its 
>>> dependencies? Reinstalling gimp2 and inkscape leads to some
>>> p5.12-* modules being installed.
>> 
>> There is intentionally no way for you to do so. Ports like intltool
>> that use specific perl modules must depend on a specific perl
>> version thereof. Currently the default perl in MacPorts is 5.12.
>> I'm sure we'd be willing to entertain the idea of changing what the
>> default perl is, but it should then be done uniformly in all
>> ports.
> 
> Again, I would have assumed that upgrading perl would replace the
> older version with the newer one, and therefore rebuilding all ports
> depending on older versions, now depending on newer ones. But also
> again, I am not an expert.

Sorry, that's not going to happen, with the way perl currently is in MacPorts, meaning that there are multiple versions available.


> Of course perl is not the same as some 'simple' program, where you
> would not need more than one version. Why use e.g. gimp2.6 if you can
> use 2.8? Most users would simply install the newer one.

Right but for programming languages, we often have multiple versions available, since there are often differences between versions. Theoretically you might have one program that requires perl5.8 and another that requires perl5.12 so in that case you would need to be able to install perl5.8 and perl5.12 simultaneously. This is what the current design of the perl ports in MacPorts is designed to let you accomplish. The ruby, python and php ports have similar designs. Same for compiled languages: we have separate versioned ports for gcc, llvm and clang. Same with some database servers: we have separate versioned ports for mysql and postgresql.

In practice, perl is such a mature language that this problem almost never comes up. There is exactly one time I remember this happening: our ghc port required perl5.8 specifically and did not work with newer versions. That was only because our ghc port was years out of date. ghc has been updated since then so this issue no longer affects any MacPorts ports, to my knowledge. Of course we have no way of knowing about other non-MacPorts software users may be running on their systems.

We used to have just a single perl5 port in MacPorts, then some years ago it was split into multiple versions as you see it today. It has been mentioned before that for a mature language like perl this may be more trouble than it's worth and maybe we should combine them again.