[MacPorts] #67869: p5* ports - what a mess!
MacPorts
noreply at macports.org
Sun Jul 30 13:44:04 UTC 2023
#67869: p5* ports - what a mess!
--------------------+--------------------
Reporter: RJVB | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Keywords: | Port: perl5
--------------------+--------------------
Sorry for the title, but someone has to say it. I've hesitated between
"defect", "enhancement" and "request" for the ticket type but went with
"defect" in the end. Feel free to change that.
Regularly I find that perl5 ports I have installed and depended on on 1
system have disappeared when I try to install them on another system.
There used to be a time (IIRC) where one could just depend on `port:perl5`
and whatever `port:p5-foo` were required. That's probably still the case
for the main port but it just doesn't work anymore for the others.
What's the rationale for not including all versions from the main port in
the `p5-foo` ports? For instance, in the snapshot of the main repo I have
I see that `port:perl5` has `Sub-ports: perl5.16, perl5.18, perl5.20,
perl5.22, perl5.24, perl5.26, perl5.28, perl5.30, perl5.32, perl5.34,
perl5.36` but the p5-foo ports have `perl5.branches 5.28 5.30 5.32 5.34` .
That can't be right (and frankly, that variable should be set in a PG and
only overridden in individual Portfiles when unavoidable).
Also, I see the perl5 PG now ''misdefines'' `perl5.major` as
`major.minor`, which is probably part of the reason of the mess.
I am aware that some of the `p5.xy-foo` ports install binary shared
libraries, but as far as I can tell the ones I have installed on this
machine do not link to libraries provided by the corresponding
`port:perl5.xy`.
I do not see any evidence that perl is included in the `port select`
mechanism.
In other words, wouldn't it be much cleaner to provide a `port:perl5` that
is not just a dependent but installs an actual default version of perl5,
which gets updated regularly but not more often than strictly necessary,
and which can be used preferentially for things like build dependencies?
Updating that main-default port would only have to trigger a rebuild of
the corresponding p5-foo ports when there's been a ABI break (very rare, I
assume since Linux distros do not seem to maintain separate lineages of
perl packages).
This would address the issues I'm referring to above, and also put an end
to (a priori) the ever-increasing amount of obsolete p5-foo ports that
never get cleaned up if the user doesn't do it because "who knows what
they're needed for".
Having such a main/default perl5 version is not incompatible with having a
number of specific versions with their corresponding p5-foo ports, for
users who have specific needs.
----
Of course it would also be possible to allow ''advanced'' users to set a
preferred perl5 version in `macports.conf` (which would get included in
`perl5.branches`) - and let the perl5 PG print out a warning when it's
really time to bump that version.
--
Ticket URL: <https://trac.macports.org/ticket/67869>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list