Front page | perl.perl5.porters |
Postings from July 2020
Re: Perl 7 - updates
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
July 5, 2020 10:38
Subject:
Re: Perl 7 - updates
Message ID:
8d9f43cb-84ff-c3c4-56ad-401fa5363cbf@gmail.com
On 7/5/20 1:13 PM, Leon Timmermans wrote:
> On Sat, Jul 4, 2020 at 1:26 AM Sawyer X <xsawyerx@gmail.com> 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,
right?
>
> 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