randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

[Ryan Schmidt]

On Jun 22, 2020, at 23:21, Nils Breunese wrote:

> Jason Liu wrote:
> 
>> Would it be possible to sort of split the difference? i.e. not _just_ have one single perl5 port and get rid of all the individual point releases, but rather to add perl5 as a sort of "metapackage" that is essentially the same as perl5.30. I guess metapackage isn't the right word, either. In reality more like, it's the same package as perl5.30, but simply with a more generic name that maps to whatever specific release has been blessed as the MacPorts default perl. So, these ports would all exist:
>> 
>> 	• perl5 <= the "metapackage", and is actually the same port as perl5.30, perl5.32, or whatever is deemed to be the current MacPorts default perl.
>> 	• perl5.30
>> 	• perl5.28
>> 	• perl5.26
>> 	• ...
>> So if a particular port is okay with blindly using a version of perl that tracks with the latest MacPorts default perl, they can use perl5. If a port breaks when the MacPorts default perl gets changed, then the port could still revert back to specifying a specific version of perl, by simply changing the perl5 to perl5.28.
> 
> There already is a perl5 wrapper port: https://ports.macports.org/port/perl5/summary
> 
> Its version is currently 5.26.1 and it has perl5_26, perl5_28 and perl5_30 variants.

Yes, but that's for users to use. It's not for ports to declare a dependency on, unless they don't need any perl modules.

The perl5 port is also unique and not a pattern we want other ports to follow. Other ports (python, php, etc.) instead use the "select" mechanism, which again is for a user's convenience and is not for other ports to rely upon.