[MacPorts] #50000: perl5: improve / reimplement packaging

[MacPorts]

#50000: perl5: improve / reimplement packaging
-----------------------------+--------------------------------
  Reporter:  mojca@…         |      Owner:  macports-tickets@…
      Type:  enhancement     |     Status:  new
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:
Resolution:                  |   Keywords:
      Port:  perl5 perl5.22  |
-----------------------------+--------------------------------

Comment (by mojca@…):

 Here are some of my thoughts.

 === Disadvantages of current situation with many perl versions installed
 in parallel ===

   * pointless effort in many ports that work with any version of Perl
   * some programs get a `-5.x` suffix and cannot easily be found by other
 software that depends on them; a lot of special cases are needed
   * almost no way to enforce consistent variants (if one port upgrades to
 perl5.y and its dependency stays at perl5.x, things break)
   * very heterogeneous handling of ports w.r.t different perl versions
   * we seem to need more than a year to do the transition now (and nearly
 forever if one doesn't force it)
   * once users get `+perl5_16` for one port, `+perl5_18` for the other,
 ... it's very difficult to install/upgrade all ports to `+perl5_22`, so
 users get stuck on the "oldest" version forever
   * (many others, too many to mention them all)

 === Disadvantages of having just one Perl interpreter available at any
 given time ===

  * developer(s) will be "afraid" to upgrade perl5.x to perl5.(x+2)
  * at the same time the person doing the upgrade has to:
    * upgrade Perl itself
    * revbump '''all''' ports that depend on perl (probably 2000+ of them)
    * deal with a large number of failures due to early adoption; even if
 we upgrade late, problems still won't show up until people actually do the
 upgrade
  * inability to avoid failures on particular ports that will be
 incompatible with the latest version, with basically no grace period and
 zero testing

 In comparison to linux distributions where most likely a fixed version of
 Perl is chosen and well tested before the official release, we have no
 "grace period", "stable vs. unstable" distribution or any easy way of
 testing or merging "massive changes".

 Perl 5.14 was released in 2011. And it took us almost five years to do the
 jump just twice (5.12 -> 5.16 -> 5.22). When we were transitioning to
 5.16, 5.16 was actually already outdated. Expecting from the maintainer of
 Perl 5 to do such a transition in an infinitely short period of time is a
 bit hard of a requirement.

 === My proposal ===

 I would thus like to propose a solution that needs quite some extra coding
 in the core, but something that is a good compromise between the two
 extremes of providing just a single version of Perl and that of letting
 every single package and user choose which version of Perl to use.

 My idea is the following:
   * ban the idea of `port select` for perl (remove any traces of it) as it
 is not suitable/flexible enough for what we need and almost impossible to
 use
   * `perl5[.x]`: Different versions of Perl are still supported and
 implemented in basically the same way as they are now. We could
 theoretically provide an arbitrary number of working versions of Perl (I
 don't see a compelling need to remove old Perls).
   * `p5-foo` modules:
     * We put additional amount of work to simplify packaging (to be
 discussed separately).
     * But basically we would still allow parallel installations of
 `p5.22-foo` and `p5.24-foo`.
     * I would love it if there was no need to manually specify the
 complete list `"5.20 5.22 5.24"` etc. in every single port and if we could
 implement some trick in `Portindex` and buildbots to see and build the
 ports nonetheless when new perl versions are added. (Yes, this needs an
 extension to the code in core.) Failing to implement this point would just
 mean a tiny bit more work, but that work can be fully automated, so it's
 not that bad after all.
     * `p5-foo` would have multiple conflicting variants like `+perl5_22
 +perl5_24` with `p5-foo +perl5_22` declaring dependency on `p5.22-foo`.
     * Other ports would declare dependency on `p5-foo` rather than on
 `p5.22-foo`.
   * Ports that just use Perl and don't link against perl's dylib or
 install modules under `${prefix}/lib/perl5/vendor_perl/5.x/`:
     * These ports would depend on `perl5` and `p5-foo`.
     * Their scripts would be executed with `${prefix}/bin/perl` (or maybe
 `${prefix}/bin/perl5` just to be on the safe side :)
     * After an upgrade of Perl (the official switch of the default
 version), there will be no need to revbump the port or do anything else
 with it. It should just keep working.
     * (These ports could still include the perl5 PortGroup if necessary.)
   * Ports that link against `libperl.dylib` or install files under
 `${prefix}/lib/perl5/vendor_perl/5.x/` or have some part of perl hardcoded
 in some way:
     * These ports should include `"PortGroup perl5 1.x"` and
 `"perl5.something_to_create_variants"` in the `Portfile`.
     * When default version of Perl changes, these ports won't need a
 revbump either because users would replace `foo +perl5_x` with `foo
 +perl5_(x+2)`.
     * But the ports will need a rebuild on the buildbots to get binary
 packages with the new default variant.
   * Switching from one version of perl to another:
     * The macports base should enforce the use of consistent variants
 across the complete installation (in a similar way as it enforces
 `+universal` on all dependencies).
     * We should implement a special command that does the switch.
       * The command would go through the list of all ports with an active
 `+perl5_x` variant and reinstall all of the ports with `+perl5_y`.
       * `p5.x-foo` modules would remain installed (they would not be
 removed or `replaced_by` until the graveyard replaces them with the latest
 version).
       * `p5-foo +perl5_x` would be replaced with `p5-foo +perl5_y`,
 installing `p5.y-foo` if necessary.
       * All other `foo +perl5_x` would be replaced by `foo +perl5_y` in a
 proper order to make sure that dependencies get changed first.
       * Some special safeguards need to be implemented for cases when the
 transition gets interrupted in the middle of the process.
   * At any given time we would basically keep just the latest two
 maintained versions (or one of them):
     * Brave developers would be free to try `perl5.(2n+1)` on their own,
 without having to do an unreasonable amount of work to get development
 releases working.
     * As soon as a new stable release comes out, the perl5 maintainer
 prepares a new port (say, `perl5.24`), increases the list of available
 default variants, adds subports for perl modules `p5.24-foo` and variants
 to ports that need them. At that point regular users don't get
 automatically upgraded and basically don't notice the change, but brave
 developers can easily switch to that new version.
     * Sufficient time (several months up to a year?) to fix problems.
     * Once brave developers & users reach a consensus that the new version
 of Perl is usable and stable enough (probably a couple of months after the
 new release is out), the global default in MacPorts is changed. I'm not
 sure how to enfornce that change to users (they could get a warning/note
 that they should issue a particular command), but users can still switch
 back and forth between the two versions as they please.
     * Once the consensus is reached that the new version works fine, or
 around the time when the old version is no longer maintained, we remove
 the subports and variants for that version, again ending up with either a
 single version or possibly replacing the old version with the new one.
 Users that sticked with that version should get an automatic upgrade at
 that point at latest.

 What we need:
   * A more advanced tool to help port maintainers *automatically*
 determine:
     * The list of dependencies (tracemode should be able to provide that
 list).
     * Whether a port is `noarch`.
     * Whether a port links against `perl5.dylib` or installs versions-
 specific files/modules for Perl somewhere.
   * Both more advanced and more lightweight basic functionality of the
 perl5 PortGroup, so that maintainers won't have to think twice about
 consequences before including the PortGroup in their ports.
     * Automatic generation of variants `+perl5_x` (with one rather than
 five lines of code).
     * A better name for `${perl5.major}` :)
   * Buildbot:
     * A doable way to rebuild all ports with the new `+perl5_x` variant.
   * Portindex:
     * Ability to reindex ports containing
 `"perl5.something_to_create_variants"` when the set of available variants
 increases.
   * Graveyard
     * More efficient build with `portindex` and more efficient failures on
 the buildbot.
   * ...

-- 
Ticket URL: <https://trac.macports.org/ticket/50000#comment:4>
MacPorts <https://www.macports.org/>
Ports system for OS X