develooper Front page | perl.perl5.porters | Postings from July 2020

Re: Perl 7 - updates

Thread Previous | Thread Next
Sawyer X
July 5, 2020 10:38
Re: Perl 7 - updates
Message ID:

On 7/5/20 1:13 PM, Leon Timmermans wrote:
> On Sat, Jul 4, 2020 at 1:26 AM Sawyer X <> wrote:
>> We do not own /usr/bin/perl but we do produce binaries and provide
>> suggestions for distributions (which they are free to ignore, of course).
>> I think we have three major options with binaries:
>> 1. We can produce a "perl7" binary and recommend to distributions this
>> be "/usr/bin/perl7". The benefit is clear: Existing users change nothing
>> and will continue to stay on Perl 5 until they decide to change their
>> shebang, command line, or the distribution fixes enough to, by default,
>> point "/usr/bin/perl" to it. The downside is all-new developers, or
>> those that want to move to the next version, will need to use a new
>> shebang, a new command line, and basically, we're forcing them to pay a
>> cost they might not.
>> 2. We can produce a different binary, "perl$foo". This is similar to #1,
>> except this can be a rolling binary like "perl" is. It's one less dance
>> for distributions between symlinks, though it might be even harder on
>> them. The additional problem with that is that it essentially "forks"
>> the binary name for Perl. I would hard-pressed to find a suitable name,
>> but it's worth bikeshedding. The confusion for beginners would grow with
>> this option, though. Over time, it might be a better option.
>> 3. We continue to produce a "perl" binary and recommend distributions to
>> change the Perl 5 binary to be "/usr/bin/perl5". This is the opposite of
>> #1 and puts the entire weight on existing code.
>> We should discuss these options, as well.
> PEP 394, the system that python eventually adopted, seems like it
> would the sensible solution to me. We mandate that /usr/bin/perl5 and
> /usr/bin/perl7 both do the obvious and leave /usr/bin/perl entirely to
> the distributors.

I agree with you. In this case, we're still producing a "perl" binary, 

> The bigger challenge may be what to do with corelist, cpan, enc2xs,
> encguess, h2ph, h2xs, instmodsh, json_pp, libnetcfg, perlbug, perldoc,
> perlivp, perlthanks, piconv, pl2pm, pod2html, pod2man, pod2text,
> pod2usage podchecker, podselect, prove, ptar, ptardiff, ptargrep,
> shasum, splain, xsubpp, zipdetails.

You're right. We should discuss them further.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About