On 2022-7-5 22:54 , Mojca Miklavec wrote:
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).
Yes, something bad will happen: the affected ports won't run for most
users who install them after the change. However, that already happened
before for any user who had perl5 installed with a non-default variant,
and will be happening more since my PR changing the default variant was
merged. Removing the perl5_28 variant will unhide the problem for the
final segment of users (those who already have perl5 installed with the
old default variant).
#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.
My vote would be the maintainer's choice of (a) or (c), but always using
perl5.major as the variable name in the (a) case.
- Josh
