<div dir="ltr"><div>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:</div><div><br></div><ul><li>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.</li><li>perl5.30</li><li>perl5.28</li><li>perl5.26</li><li>...</li></ul><div>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.</div><div><br></div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- </div><div>Jason Liu<br></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 22, 2020 at 11:21 PM Ryan Schmidt <<a href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've just realized this discussion has been to the old list address from macosforge. Please always use the new list addresses at <a href="http://lists.macports.org" rel="noreferrer" target="_blank">lists.macports.org</a>.<br>
<br>
<br>
On Jun 22, 2020, at 14:34, Daniel J. Luke wrote:<br>
<br>
> We should just have one perl5 port that tracks the current release.<br>
<br>
You say this every year (or at least often).<br>
<br>
Are you volunteering to be the one to ensure that every port that uses perl is compatible with the new perl release when it comes out? Without someone to do that, blindly upgrading everything from say perl 5.28 to 5.30 will likely break ports.<br>
<br>
Do you remember perl 5.26? It broke a lot of ports, requiring a lot of fixes like this to be added: <a href="https://github.com/macports/macports-ports/commit/454eb2b0608266ab7bdf51a82d690be0f97610fe" rel="noreferrer" target="_blank">https://github.com/macports/macports-ports/commit/454eb2b0608266ab7bdf51a82d690be0f97610fe</a><br>
<br>
The strategy currently being employed by those volunteers who are maintaining the perl ports is to keep everything defaulted to 5.28 for now, add 5.30 ports and fix problems in them as they're found, and once everything is building then switch the default to 5.30. This seems sensible to me.<br>
<br>
</blockquote></div>