Let's bump the minimum Perl version to 5.8

On Fri, Sep 24, 2010 at 11:22, Tor Arntsen <tor@spacetec.no> wrote:

It matters because you keep saying "5.6", which is ambiguous since the syntax in question was introduced in 5.6.1. The error you may be having on 5.6.0 is very different from 5.6.1, and 5.6.2 has additional bugfixes:

    http://search.cpan.org/~jesse/perl-5.12.2/pod/perl561delta.pod#open()_with_more_than_two_arguments

Anyway, I compiled maint-5.6 from perl.git and confirmed this:

    $ /home/avar/perl5/installed/bin/perl5.6.2 -Mdiagnostics -le
'print $]; sub run_cmd_pipe { my $fh = undef; open($fh, "-|", @_) or
die;  return <$fh>; } print run_cmd_pipe(qw(git --help));'
    5.006002
    Can't use an undefined value as filehandle reference at -e line 1 (#1)
        (F) A value used as either a hard reference or a symbolic reference must
        be a defined value.  This helps to delurk some insidious errors.

    Uncaught exception from user code:
            Can't use an undefined value as filehandle reference at -e line 1.
            main::run_cmd_pipe('git', '--help') called at -e line 1

As compared to a more recent perl:

    $ perl -Mdiagnostics -le 'print $]; sub run_cmd_pipe { my $fh =
undef; open($fh, "-|", @_) or die;  return <$fh>; } print
run_cmd_pipe(qw(git --help));'
    5.013004
    usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]
    [...]

And to reply to Alex Riesen I can't get this to work with `my $fh` (which would be undef too) or glob open either. Although it should be possible with other types of pipe open, or even using temporary files.

    $ /home/avar/perl5/installed/bin/perl5.6.2 -Mdiagnostics -le
'print $]; sub run_cmd_pipe { local *TMP; open(TMP, "-|", @_) or die;
return <TMP>; } print run_cmd_pipe(qw(git --help));'
    5.006002
    Can't use an undefined value as filehandle reference at -e line 1 (#1)
        (F) A value used as either a hard reference or a symbolic reference must
        be a defined value.  This helps to delurk some insidious errors.

    Uncaught exception from user code:
            Can't use an undefined value as filehandle reference at -e line 1.
            main::run_cmd_pipe('git', '--help') called at -e line 1

However, I'd like to shift the discussion a bit: Do we want to support the 5.6 line *at all* anymore? I don't think so. As you point out yourself you can just compile 5.8 or later on these machines.

I just tried running our test suite with maint-5.6 after compiling with:

    NO_PERL_MAKEMAKER=1
PERL_PATH=/home/avar/perl5/installed/bin/perl5.6.2
prefix=/opt/git/perl-56 all install

NO_PERL_MAKEMAKER=1 is needed because the ExtUtils::MakeMaker that comes with 5.6.2 doesn't know how to move perl/private-Error.pm to perl/blib/*/Error.pm. So if you don't provide it you'll get:

    $ /opt/git/perl-56/bin/git add -p
    Can't locate Error.pm

That would also break e.g. git-send-email.

Here are the test results *without* NO_PERL_MAKEMAKER=1, for reference:

    Test Summary Report
    -------------------
    t2016-checkout-patch.sh                          (Wstat: 256
Tests: 14 Failed: 12)
      Failed tests:  2-13
      Non-zero exit status: 1
    t3701-add-interactive.sh                         (Wstat: 256
Tests: 33 Failed: 17)
      Failed tests:  2, 4-5, 7, 9-10, 13, 16, 18, 21-25, 29
                    31, 33
      Non-zero exit status: 1
    t3904-stash-patch.sh                             (Wstat: 256
Tests: 5 Failed: 2)
      Failed tests:  3-4
      Non-zero exit status: 1
    t7105-reset-patch.sh                             (Wstat: 256
Tests: 8 Failed: 6)
      Failed tests:  2-7
      Non-zero exit status: 1
    t7501-commit.sh                                  (Wstat: 256
Tests: 42 Failed: 1)
      Failed test:  21
      Non-zero exit status: 1
    t7800-difftool.sh                                (Wstat: 256
Tests: 22 Failed: 21)
      Failed tests:  2-22
      Non-zero exit status: 1
    t9700-perl-git.sh                                (Wstat: 256
Tests: 2 Failed: 1)
      Failed test:  2
      Non-zero exit status: 1
      Parse errors: No plan found in TAP output
    t9001-send-email.sh                              (Wstat: 256
Tests: 85 Failed: 59)
      Failed tests:  4-7, 9-10, 12-13, 15, 17-20, 22, 24, 26
                    28-30, 32, 34, 36, 38, 40, 42, 44, 46, 48-55
                    58-77, 80-82, 85
      Non-zero exit status: 1

And with NO_PERL_MAKEMAKER=1:

    Test Summary Report
    -------------------
    t2016-checkout-patch.sh                          (Wstat: 256
Tests: 14 Failed: 12)
      Failed tests:  2-13
      Non-zero exit status: 1
    t3904-stash-patch.sh                             (Wstat: 256
Tests: 5 Failed: 2)
      Failed tests:  3-4
      Non-zero exit status: 1
    t3701-add-interactive.sh                         (Wstat: 256
Tests: 33 Failed: 17)
      Failed tests:  2, 4-5, 7, 9-10, 13, 16, 18, 21-25, 29
                    31, 33
      Non-zero exit status: 1
    t7105-reset-patch.sh                             (Wstat: 256
Tests: 8 Failed: 6)
      Failed tests:  2-7
      Non-zero exit status: 1
    t7501-commit.sh                                  (Wstat: 256
Tests: 42 Failed: 1)
      Failed test:  21
      Non-zero exit status: 1
    t9700-perl-git.sh                                (Wstat: 256
Tests: 14 Failed: 0)
      Non-zero exit status: 1
      Parse errors: No plan found in TAP output

All but the last error are due to this bug in git-add--interactive.perl. I didn't track down what was wrong with t9700-perl-git.sh.

git-svn would have failed too if I had SVN libraries:

    $ /opt/git/perl-56/bin/git svn
    Can't locate Digest/MD5.pm in @INC [...]

Getting a working Digest::* (and anything else git-svn needs) for 5.6 at this point is a *lot* harder than just compiling 5.8 (or even better, 5.12).

Since we're not getting patches for common things that have been broken on 5.6 for years and bumping the requirenment to an 8 year old perl (5.8) instead of a 10 year old one (5.6) would make things much easier, including:

 * Fixing the perl/ Makefile mess

 * Being able to use 5.8 features

 * Being able to honestly support the 5.8 release, 5.6 doesn't even
   compile on modern systems without undocumented monkeypatches, and
   few people use it so we don't get fixes for it.

I'd like to propose dropping 5.6 support, and move to say 5.008. I can do the work required to add appropriate docs / use statements and fixes to bugs that we can't fix on 5.6.

On Fri, Sep 24, 2010 at 14:56, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

5.8 as minimum is probably for the best. It's not that just you can compile a newer version (5.8), more importantly, Perl 5.8 is available as a package from those semi-official 3party repositories for most systems (at least the *nix systems I have access to), except for those like Irix 6.2 where it's hopeless anyway (perl 5.0). But I only have access to irix/aix/solaris/tru64 in addition to Linux.

-Tor

On Fri, Sep 24, 2010 at 13:08, Tor Arntsen <tor@spacetec.no> wrote:

Do those repositories also have 5.10 and 5.12?

Hrm, 6.2 is old, but 5.12 is known to compile on 6.5 at least. What are the issues with 6.2? Perhaps they could be solved if someone with such a machine contributed a smoker for the perl core.

Perl is very portable with people willing to port it, the main limitation is usually that porters don't have access to obscure systems, not that there isn't interest.

On 09/24/2010 03:32 PM, Ævar Arnfjörð Bjarmason wrote:

Fedora 13 ships with Perl 5.10.0. IIRC, Fedora 12 (or possibly 11) shipped with Perl 5.8. Let's not ask for more angry users than we can handle. Since the current code seems to work fine with 5.8 and later, I think that's a safe minimum to require for full git functionality. Especially considering it was 3 years since we decided on 5.6, which was by then 7 years old.

On Fri, Sep 24, 2010 at 13:59, Andreas Ericsson <ae@op5.se> wrote:

I didn't mean to suggest we bump to 5.10 now. I just thought I'd ask for the record in case we have this discussion again 3-4 years from now.

Do you happen to have a link to that discussion? I can't find it.

On 09/24/2010 09:10 PM, Ævar Arnfjörð Bjarmason wrote:

I was writing from memory, and I was wrong. Commit messages seems to point to february 2006 as the "let's be Perl 5.6 compatible" time.

  git log --grep="Perl.*5.6"

might prove useful. 4.5 years then, and not 3. My, how time flies.

On Fri, Sep 24, 2010 at 15:32, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Anything later than 5.8 seems to very unusual except for Linux (and presumably *bsd).

IRIX 6.2 is simply suffering for being old. Unless you have to maintain a legacy system (as I do) you would probably have upgraded to IRIX 6.5 anyway. (Actually it turns out that I wasn't entirely correct in what I wrote earlier - the SGI freeware version of Perl for IRIX 6.5 is still at 5.6.1, because they stopped updating that repository. There's another 3party semi-official repo for IRIX now, not hosted by SGI, but I'm not familiar with it.

People interested in installing Git will probably first want to look for a pre-made package, and, if not, build it themselves. At that point, however, they would probably give up if it turns out they have to start building the underlying stuff (e.g. Perl) themselves too, so I tend to look for the lowest common denominator for 3party packages (e.g. 5.8 if we can get away with it, not 5.10). IRIX 6.5 is a bit unfortunate in this though. IRIX 6.2 can be considered an unlikely corner case.

-Tor

On Sep 24, 2010, at 10:08 AM, Tor Arntsen wrote:

Based on www.opensource.apple.com, OS X started having 5.8 in OS X 10.3.0.  (And has only had 5.10 starting with 10.6.)  I don't know if macports or fink still support older OS X versions, so likely a 5.8 requirement would make anyone OS X older than 10.3 build perl-5.8 from source.

Just FYI, ~~ Brian

Tor Arntsen wrote:

In Linux land atleast the current crop of RHEL dists are on 5.8.x and for RHEL5 this is supported until 2014 (2017 with ELS).

There are currently 2 maintained options for IRIX users: nekochan (requires IRIX 6.5.21 or better) tgcware (IRIX 5.3 & 6.2, will also run on 6.3, 6.4, 6.5).

I maintain tgcware and have prebuilt git packages available (1.7.2.3).

Git does not build on IRIX < 6.3 without adding some sort of thirdparty (v)snprintf code since those functions are missing in libc. I use the ctrio library for this purpose.

-tgc

Le 24/09/2010 15:08, Tor Arntsen a écrit :

5.10 is available on Cygwin.

Pascal.

On Sep 24, 2010, at 10:38 AM, Pascal Obry wrote:

Lamp doesn't have 5.8 (only 5.6.1), but it doesn't have svn, either.

Josh

Ævar> Since we're not getting patches for common things that have been Ævar> broken on 5.6 for years and bumping the requirenment to an 8 year old Ævar> perl (5.8) instead of a 10 year old one (5.6) would make things much Ævar> easier, including:

Ævar>  * Fixing the perl/ Makefile mess

Ævar>  * Being able to use 5.8 features

Ævar> * Being able to honestly support the 5.8 release, 5.6 doesn't even Ævar> compile on modern systems without undocumented monkeypatches, and Ævar> few people use it so we don't get fixes for it.

Ævar> I'd like to propose dropping 5.6 support, and move to say 5.008. I can Ævar> do the work required to add appropriate docs / use statements and Ævar> fixes to bugs that we can't fix on 5.6.

As the token resident Perl expert, I'd be completely fine with that. Sane choice.

It might be useful to document that by adding:

  require 5.008;

at the beginning of each file that presumes it, as you get around to editing it.

That way, Perl won't even try to run it if it's too old.

On Fri, Sep 24, 2010 at 13:47, Randal L. Schwartz <merlyn@stonehenge.com> wrote:

Right, except that should be `use 5.008`. Since you don't want to run anything else within an implicit or explicit BEGIN block before perl fails on that. E.g. `require 5.008; use Digest::MD5;` would just spew an error about Digest::MD5.

The only reason you'd want `require $version' is if you care about 5.005, but even then you can do `BEGIN { require 5.008 }`.

Ævar> Right, except that should be `use 5.008`. Since you don't want to run Ævar> anything else within an implicit or explicit BEGIN block before perl Ævar> fails on that. E.g. `require 5.008; use Digest::MD5;` would just spew Ævar> an error about Digest::MD5.

Fairy 'nuff.

Formalize our dependency on perl 5.8, bumped from 5.6.[12]. We already used the three-arg form of open() which was introduced in 5.6.1, but t/t9700/test.pl explicitly depended on 5.6.2.

However git-add--interactive.pl has been failing on the 5.6 line since it was introduced in v1.5.0-rc0~12^2~2 back in 2006 due to this open syntax:

    sub run_cmd_pipe {
           my $fh = undef;
           open($fh, '-|', @_) or die;
           return <$fh>;
    }

Which when executed dies on "Can't use an undefined value as filehandle reference". Several of our tests also fail on 5.6 (even more when compiled with NO_PERL_MAKEMAKER=1):

    t2016-checkout-patch.sh
    t3904-stash-patch.sh
    t3701-add-interactive.sh
    t7105-reset-patch.sh
    t7501-commit.sh
    t9700-perl-git.sh

Our code is bitrotting on 5.6 with no-one interested in fixing it, and pinning us to such an ancient release of Perl is keeping us from using useful features introduced in the 5.8 release.

The 5.6 series is now over 10 years old, and the 5.6.2 maintenance release almost 7. 5.8 on the other hand is more than 8 years old.

All the modern Unix-like operating systems have now upgraded to it or a later version, and 5.8 packages are available for old IRIX, AIX Solaris and Tru64 systems.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Tor Arntsen <tor@spacetec.no>
Acked-by: Randal L. Schwartz <merlyn@stonehenge.com>
---

A follow-up to the discussion in "Let's bump the minimum Perl version to 5.8". I took the liberty of adding Tor and Randal's Acked-by to the patch based on their comments in the thread. Which is why this is an RFC, if they're OK with it it can be applied.

 INSTALL                    |    8 ++++----
 git-add--interactive.perl  |    1 +
 git-archimport.perl        |    1 +
 git-cvsexportcommit.perl   |    1 +
 git-cvsimport.perl         |    1 +
 git-cvsserver.perl         |    1 +
 git-difftool.perl          |    1 +
 git-relink.perl            |    2 +-
 git-send-email.perl        |    1 +
 git-svn.perl               |    1 +
 gitweb/gitweb.perl         |    1 +
 perl/Git.pm                |    1 +
 t/t7006/test-terminal.perl |    1 +
 t/t9700/test.pl            |    2 +-
 14 files changed, 17 insertions(+), 6 deletions(-)

On Fri, Sep 24, 2010 at 22:00, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

This is OK with me.

-Tor

Ævar Arnfjörð Bjarmason wrote:

This issue and possible solutions was previously discussed in-depth here: http://article.gmane.org/gmane.comp.version-control.git/94394

FWIW I build rpms and run git on RHEL 2.1 with perl 5.6.1.

These are the settings I use: NO_CURL=1 (curl 7.8.1 is too old) NO_TCLTK=1 (tcl/tk 8.3 is too old) NO_NSEC=1 NO_EXTERNAL_GREP=1 (GNU grep 2.4.2 is apparently too old) NO_REGEX=1 (glibc regex breaks t7008.11, also needed for el3) NO_PERL_MAKEMAKER=1 (ExtUtils::MakeMaker is too old)

GIT_SKIP_TESTS="t2016 t3701 t3904 t7105 t7501.21"

Additionally to fix NO_PERL_MAKEMAKER I use this patch: http://article.gmane.org/gmane.comp.version-control.git/130159

To build with OpenSSL 0.9.6 I also add this in git-compat-util.h: # if SSLEAY_VERSION_NUMBER < 0x00907000L # define HMAC_CTX_cleanup HMAC_cleanup # endif

With these settings I have zero testsuite failures (just verified with 1.7.3). t9700 is automatically skipped because Test::More is not available in perl 5.6.1. gitweb requires 5.8 and is also skipped automatically. I do not have subversion available on RHEL 2.1 so those tests are also skipped. CVS server/import tests are skipped because I do not have cvsps and perl-SQLite available.

IIRC there has been no change in the functionality with perl 5.6.1 since the last time the 'open syntax' issue was discussed.

Having the specific parts known not to work with perl 5.6.x fail gracefully at runtime would be an improvement.

-tgc

Change the Perl scripts to turn on lexical warnings instead of setting the global $^W variable via the -w switch.

The -w sets warnings for all code that interpreter runs, while "use warnings" is lexically scoped. The former is probably not what the authors wanted.

As an auxiliary benefit it's now possible to build Git with:

    PERL_PATH='/usr/bin/env perl'

Which would previously result in failures, since "#!/usr/bin/env perl -w" doesn't work as a shebang.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---

This is a re-send, it's independent of bumping the version to 5.8 (use warnings was introduced in 5.6), but a good idea anyway.

 contrib/examples/git-svnimport.perl         |    2 +-
 contrib/fast-import/import-directories.perl |    3 ++-
 git-add--interactive.perl                   |    3 ++-
 git-archimport.perl                         |    2 +-
 git-cvsexportcommit.perl                    |    3 ++-
 git-cvsimport.perl                          |    2 +-
 git-send-email.perl                         |    2 +-
 7 files changed, 10 insertions(+), 7 deletions(-)