perl5: improve / reimplement packaging

[mojca (Mojca Miklavec)]

I'm opening this ticket to collect and vote on ideas with their pros and cons about different options to package:

• perl5[.x]
• perl modules p5[.x]-foo
• ports that depend on Perl
• perl6

Desired features:

• easy updates of perl modules, possibly (semi-)automated from metadata from CPAN
• painless upgrades from perl5.[n] to perl5.[n+1]
• reasonably small effort with modifying and revbumping all the ports that depend on Perl

Some particular aspects to think about:

• a port could have a flag (possibly "auto-generated") to indicate that there is no difference in what Perl version is being used (other than maybe path to perl, but path could be version-neutral); those ports won't need any revbumps after changing the version
• ...

Please try to think out of the box and and come up with proposals even if implementing them is not yet supported by the base. We can extend the base if we know exactly what we want to achieve.

Some relevant tickets that have been open for a long time already:

• #29763

  *_select framework does not apply to Perl: fix provided

  #36980

  perl5.x: sitebin & vendorbin flags may be inapproriate

  #43741

  cpan fails to install any module

(No need to rush into any decisions and implementations before we carefully think of all the consequences of that particular implementation.)

[RJVB (René Bertin)]

Some thoughts:

• ports that only require the perl interpreter (plus potentially perl scripts), be it as a build or runtime dependency should not have to include a perl PortGroup, ideally. Dependencies like port:perl5 (or port:perl6) and port:p5-uri should be enough.
• runtime dependencies of this sort should not require a revbump if perl gets updated, unless the update introduces an incompatibility or regression. I think the same applies to build dependencies of this sort (isn't perl often used to generate/translate documentation?) though the reproducible build principle may impose otherwise.
• to ease the revbumping burden (and reduce useless rebuilds), it might be good to agree on a way for ports to indicate that they don't care about the exact perl version (and thus can be skipped when revbumping).

• surely a brilliant MacPorts dev could find a way to remove the need to reinstall all those perl packages at each minor version upgrade? O:-)

Edit: congrats Mojca, you made the 50k mark ;)