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.
