[MacPorts] #67869: p5* ports - what a mess (IMHO, YMMV &c! (was: p5* ports - what a mess!)

[MacPorts]

#67869: p5* ports - what a mess (IMHO, YMMV &c!
---------------------+--------------------
  Reporter:  RJVB    |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:  perl5   |
---------------------+--------------------

Comment (by RJVB):

 Replying to [comment:2 ryandesign]:

 The title was meant to be provocative but I could have made it more clear
 that it's my opinion.

 > It has been this way since perl5 and the p5- ports were split into
 submodules in 2011 (#30638).

 MacPorts has evolved considerably since then, so there must be a more
 convenient and cleaner way to do this nowadays.

 > Granted that commit message does not say why but there was probably
 mailing list discussion approving the plan

 But who goes scavenging through mailing list archives to find such
 discussions?!

 > > (and frankly, that variable should be set in a PG and only overridden
 in individual Portfiles when unavoidable).
 >
 > No. Portfiles are only indexed when they are modified.

 As a sidebar, that too is something that could end probably should be
 modified because it's counter-intuitive to anyone used to programming.
 But the revision mechanism exists for this purpose, which probably a whole
 lot simpler to use in a script than a more complex edit.
 Also, it is not impossible that the majority of ports do not need to be
 revbumped. As you say, perl5 is mature and rarely breaks ABI, very few
 perl ports install binaries (2 our of 146 for me; they do not link to
 libperl.dylib) and the rest simply don't need to be revbumped unless there
 are known incompatibilities.

 > > Also, I see the perl5 PG now ''misdefines'' `perl5.major` as
 `major.minor`, which is probably part of the reason of the mess.
 >
 > As far as I know, the perl module ports work as intended, so I would
 hesitate to say that anything is misdefined. How is `perl5.major` defined,
 and how do you think it should be defined instead?

 `perl5.major` is currently defined as `major.minor` (so 5.28 in the
 current snapshot I have). Now I haven't checked if there's a Perl 6 but a
 priori the major version here is `5`.

 > Correct, it is not.

 So that's a good thing for the kind of change I was proposing.

 > The pros and cons of switching to that method could be discussed. One
 con is that it be different from how we handle most other languages in
 MacPorts (python, php, ruby...).

 I cannot speak for the other two, but Python is different here in that
 binaries are much more common and they do link to a library from the main
 port. Plus the language is designed to have a version-specific "site-
 packages" or "dist" directory where packages are installed. Perl doesn't
 seem to have that (which is already a good indication that it isn't
 necessary).

 > But it took considerable effort (even the invention of the subport
 feature of MacPorts!) to implement it in the first place and it would take
 considerable effort to de-implement it again, even if we agreed it was a
 good idea to do so.

 As I said, there's no need to de-implement it. Either the p5-* ports start
 depending on `port:perl5` which provides some default version or there
 could be a `port:perl5.x` (x not being a number) with the corresponding
 p5.x-* ports. The former approach should be transparent for all ports that
 are now version-agnostic dependent on perl5.

 >  The user is expected to run `sudo port reclaim` (or just `sudo port
 uninstall obsolete`) periodically.

 I assume that gives very little control over what gets uninstalled, just
 like the `-u` option will uninstall all older (if not all other) versions
 of a port. Fine for Joe & Jane User but for more advanced users who always
 want to keep at least 1 older version around it's just not an option.

 > I don't think macports.conf at present contains any settings related to
 any specific port or portgroup and it's probably good to keep it that way.

 You can set default variants in there (or an equivalent file), which can
 very well be specific to a single port or portgroup. Idem for the
 environment variables to preserve (I don't know if the feature is used
 that way or if it would be condoned).
 NB: the perl5 PG defines variants for perl5 versions. I don't see a clear
 documentation in the PG what this is supposed to do but using a version-
 specific variant would do the trick just as well (though more awkwardly)
 as using a version-defining variable.

-- 
Ticket URL: <https://trac.macports.org/ticket/67869#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS