perl5 default version

Mojca Miklavec mojca at macports.org
Tue Jul 5 12:54:52 UTC 2022


Hi,

I would like to clarify a few points before being able to proceed:

#1
Some ports are probably not yet handling perl correctly in the sense
that they might have been built on the buildbot and keep depending on
modules from perl5.28, while the user only has perl5.34 installed.
Will something bad happen if I remove the +perl5_28 variant from the
perl5 port before those ports are "fixed"? I would just like to know
if I can merge https://github.com/macports/macports-ports/pull/15264
as is or if I need to wait with variant removal a bit longer (if I
need to remove one commit from the PR).

#2
Let's assume there's an average port that doesn't care which version
of perl is being used, but that port has a bunch of dependencies on
various perl modules (so when perl is upgraded, at least a revbump is
needed). What syntax should we use?

(a) Some ports use
    set perl_branch 5.34
    depends_build port:p${perl_branch}-xml-parser
The advantage is that a portgroup isn't needed, but one cannot use
${perl5.bin} if needed, for example.

(b) Other ports use
    PortGroup perl5 1.0
    perl5.branches 5.34
    depends_build port:p${perl5.major}-xml-parser

(c) Yet other ports use
    PortGroup perl5 1.0
    perl5.major 5.34
    depends_build port:p${perl5.major}-xml-parser

Can we agree which syntax is best (b, c, something else, ...)? Some
maintainers argued that including the PortGroup sounded like an
overkill, but it would be of enormous help if we could identify all
relevant ports with some simple grepp-ing in the future, and having
ports use "perl5.branches", "perl5.major", "perl_branch", "pbranch",
"perlver", ... tons of other variable names as well as hardcoded perl
versions etc. isn't exactly helping.

#3
A number of ports still need some love, any help would be appreciated.
Not because it's hard to do, but because there are a number of ports to check.
    https://github.com/macports/macports-ports/pull/15265
Before we devote them some love, we would need to clarify #2 though.

Thank you,
    Mojca

On Sun, 3 Jul 2022 at 14:31, Mojca Miklavec <mojca at macports.org> wrote:
>
> Hi,
>
> First of all: thanks a lot for the effort of migrating 100+ ports to perl 5.34.
> (I'm now confused because I got an email from Jeremy and two days
> later Joshua did all the work.)
>
> I bumped a few more in
>     https://github.com/macports/macports-ports/pull/15265
> and updated perl to 5.36 in
>     https://github.com/macports/macports-ports/pull/15264
>
> I would be grateful for some reviews and testing (I didn't do any), so
> that we could merge this quickly.
> I also suspect that a number of ports that just "piggy-back" on
> default perl version might need a revision bump, but I leave it to
> others to figure that out (some are listed in the above PR).
>
> Once these two PRs get merged, I would be grateful for a bit more help
> to remove dependencies on anything older than perl 5.34, so that we
> could delete thousands of perl subports before adding new ones for
> p5.36-*.
>
> Once we have the subports for 5.36 available, we can of course repeat
> the exercise of switching to 5.36 ;)
> There's no hurry for the latter, but it would at least be nice to get
> to the point where we get rid of < 5.34 and introduce support for
> 5.36.
>
> Thanks,
>     Mojca
>
> On Mon, 27 Jun 2022 at 21:54, Mojca Miklavec wrote:
> > On Mon, 27 Jun 2022 at 20:25, Jeremy Lavergne wrote:
> > >
> > > Is there a plan on when we will change the default variant version of perl5?
> >
> > I would say "as soon as we migrate the ports". But I don't know the
> > answer to the latter. Ideally it would have been a long time ago.
> >
> > > Was about to update a package that depends on perl packages, and ensure
> > > it was using the same as our default. However, it's been ahead for quite
> > > some time already. Also looks like perl 5.36 is latest stable upstream
> > > while our perl5 port seems to point to 5.28.
> >
> > 5.36 is on me.
> > But switching at least a hundred ports is a fair share of effort that
> > I cannot do alone.


More information about the macports-dev mailing list