[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