Question about PERL_PATH

Question about PERL_PATH

[Ian Abbott]

The Gentoo ebuilds for git have started invoking 'make' with the option
'PERL_PATH=/usr/bin/env perl'.  This doesn't seem to cause any problems
except when running git instaweb, which outputs an error similar to the
following:

/usr/libexec/git-core/git-instaweb: line 135: /usr/bin/env perl: No such
file or directory

There is an easy workaround, which is to modify the invocation of perl
in the httpd_is_ready() function in the git-instaweb shell script.  It
currently invokes perl as "$PERL" (with the quotes).  Removing the
quotes makes it work.

My question is, should git support Gentoo's unusual setting of PERL_PATH
as a multi-word command, or should Gentoo patch around the problem they
have created with git-instaweb themselves?

There is one other place where $PERL is used in git-instaweb and that is
in the mongoose_conf() function.  It has a heredoc that puts the
following line in the httpd.conf file (subject to shell variable expansion):

cgi_interp	$PERL

For Gentoo, that would get expanded to the following:

cgi_interp	/usr/bin/env perl

I don't know if Mongoose would choke on this or not.

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti@mev.co.uk>        )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587         )=-

Re: Question about PERL_PATH

[Michael J Gruber]

Ian Abbott venit, vidit, dixit 06.05.2011 15:30:
> The Gentoo ebuilds for git have started invoking 'make' with the option
> 'PERL_PATH=/usr/bin/env perl'.  This doesn't seem to cause any problems
> except when running git instaweb, which outputs an error similar to the
> following:

Well, it means that all our perl scripts are run with the perl which is
the first in PATH at run time (for the user running it), which may or
may not be the one which is first in PATH at build or test time (for the
user running that).

Of course there's no problem when they are the same.

> /usr/libexec/git-core/git-instaweb: line 135: /usr/bin/env perl: No such
> file or directory
> 
> There is an easy workaround, which is to modify the invocation of perl
> in the httpd_is_ready() function in the git-instaweb shell script.  It
> currently invokes perl as "$PERL" (with the quotes).  Removing the
> quotes makes it work.
> 
> My question is, should git support Gentoo's unusual setting of PERL_PATH
> as a multi-word command, or should Gentoo patch around the problem they
> have created with git-instaweb themselves?
> 
> There is one other place where $PERL is used in git-instaweb and that is
> in the mongoose_conf() function.  It has a heredoc that puts the
> following line in the httpd.conf file (subject to shell variable expansion):
> 
> cgi_interp	$PERL
> 
> For Gentoo, that would get expanded to the following:
> 
> cgi_interp	/usr/bin/env perl
> 
> I don't know if Mongoose would choke on this or not.

For a system wide installed package, it just seems like a crazy idea to
package it in a way which makes it depend on the contents of users'
$HOME/bin and such. What kind of packaging is that? I mean, package git
depends on package perl, but then leave the meaning of "perl" at the
users' discretion and mercy...

Michael

Re: Question about PERL_PATH

[Junio C Hamano]

Ian Abbott <abbotti@mev.co.uk> writes:

> The Gentoo ebuilds for git have started invoking 'make' with the option
> 'PERL_PATH=/usr/bin/env perl'.  This doesn't seem to cause any problems
> except when running git instaweb, which outputs an error similar to the
> following:
>
> /usr/libexec/git-core/git-instaweb: line 135: /usr/bin/env perl: No such
> file or directory

The variable is not PERL_COMMAND_LINE, but is PERL_PATH, so I think it
should expects the path to the program.

Our testsuite also rely on it being the path to the program by enclosing
the reference to it inside double quotes, to make sure that PERL_PATH set
to "/Program Files/Perl/perl.exe" works.  Didn't Gentoo folks see any test
breakage before shipping the ebuild procedure?

Re: Question about PERL_PATH

[Ian Abbott]

On 06/05/11 17:05, Junio C Hamano wrote:
> Ian Abbott <abbotti@mev.co.uk> writes:
> 
>> The Gentoo ebuilds for git have started invoking 'make' with the option
>> 'PERL_PATH=/usr/bin/env perl'.  This doesn't seem to cause any problems
>> except when running git instaweb, which outputs an error similar to the
>> following:
>>
>> /usr/libexec/git-core/git-instaweb: line 135: /usr/bin/env perl: No such
>> file or directory
> 
> The variable is not PERL_COMMAND_LINE, but is PERL_PATH, so I think it
> should expects the path to the program.
> 
> Our testsuite also rely on it being the path to the program by enclosing
> the reference to it inside double quotes, to make sure that PERL_PATH set
> to "/Program Files/Perl/perl.exe" works.  Didn't Gentoo folks see any test
> breakage before shipping the ebuild procedure?

Both you and Michael make excellent points and I've submitted a Gentoo
bug report mentioning this thread, so we'll see what happens!

http://bugs.gentoo.org/show_bug.cgi?id=366241

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti@mev.co.uk>        )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587         )=-

Re: Question about PERL_PATH

[Robin H. Johnson]

On Fri, May 06, 2011 at 09:05:08AM -0700,  Junio C Hamano wrote:
> The variable is not PERL_COMMAND_LINE, but is PERL_PATH, so I think it
> should expects the path to the program.
> 
> Our testsuite also rely on it being the path to the program by enclosing
> the reference to it inside double quotes, to make sure that PERL_PATH set
> to "/Program Files/Perl/perl.exe" works.  Didn't Gentoo folks see any test
> breakage before shipping the ebuild procedure?
The entire test suite completes fine with our
PERL_PATH="${EPREFIX}/usr/bin/env perl" setting.

This was originally put into place because of our bug #326625 [1].
From that bug:
====
Git does not compile if local::lib installed in user's home directory if
'sudo' is used to raise privileges. Local::lib exports environment
variable PERL5_MM_OPTS, which contains string INSTALL_BASE='...'.
Variable PREFIX is set in package's Makefile.pl. Package will not
compile if both of these variables are set.
====
(Full logs attached in the bug).

If you can suggest a better way to fix the user's bug, I'll revert the
PERL_PATH change.

1. https://bugs.gentoo.org/show_bug.cgi?id=326625

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: Question about PERL_PATH

[Jeff King]

On Sat, May 07, 2011 at 06:02:48PM +0000, Robin H. Johnson wrote:

> On Fri, May 06, 2011 at 09:05:08AM -0700,  Junio C Hamano wrote:
> > The variable is not PERL_COMMAND_LINE, but is PERL_PATH, so I think it
> > should expects the path to the program.
> > 
> > Our testsuite also rely on it being the path to the program by enclosing
> > the reference to it inside double quotes, to make sure that PERL_PATH set
> > to "/Program Files/Perl/perl.exe" works.  Didn't Gentoo folks see any test
> > breakage before shipping the ebuild procedure?
> The entire test suite completes fine with our
> PERL_PATH="${EPREFIX}/usr/bin/env perl" setting.

This is more luck than anything. For example, you are skipping all of
the perl tests (t9700) and all of the git-svn tests (t91*), because they
both try do something like:

  if ! "$PERL_PATH" -e "use SomeModule"; then
    skip_all="You don't have SomeModule installed"
  fi

So you are skipping many tests accidentally, and it is only luck that
all such uses are currently tests that handle a broken "$PERL_PATH" in
this way. It is entirely likely that this usage may end up causing a
test suite failure at some point in the future.

If we want to support this use of env/, we need to provide separate
Makefile variables for "what goes at the top of a perl script" and "what
we use to run perl".

> This was originally put into place because of our bug #326625 [1].
> From that bug:
> ====
> Git does not compile if local::lib installed in user's home directory if
> 'sudo' is used to raise privileges. Local::lib exports environment
> variable PERL5_MM_OPTS, which contains string INSTALL_BASE='...'.
> Variable PREFIX is set in package's Makefile.pl. Package will not
> compile if both of these variables are set.
> ====
> (Full logs attached in the bug).
> 
> If you can suggest a better way to fix the user's bug, I'll revert the
> PERL_PATH change.

It looks like we auto-build the perl bits of the Makefile by calling:

  $(PERL_PATH) Makefile.PL PREFIX=$(prefix) INSTALL_BASE=''

which seems to me like it should override local::lib's INSTALL_BASE
(which also doesn't seem ideal, but I wouldn't expect it to cause this
error). But surely the solution involves changing this line in
perl/Makefile to handle the local::lib case?

I also don't see how this is git-specific. From my reading of the bug
report, local::lib will fail to work any time the user does:

  perl Makefile.PL PREFIX=anything

which seems odd. Wouldn't other packages be running into this problem,
then, too (i.e., anything which has a little bit of perl and
automagically runs MakeMaker on behalf of the user)?

-Peff

Re: Question about PERL_PATH

[Drew Northup]

On Sat, 2011-05-07 at 18:02 +0000, Robin H. Johnson wrote:
> On Fri, May 06, 2011 at 09:05:08AM -0700,  Junio C Hamano wrote:
> > The variable is not PERL_COMMAND_LINE, but is PERL_PATH, so I think it
> > should expects the path to the program.
> > 
> > Our testsuite also rely on it being the path to the program by enclosing
> > the reference to it inside double quotes, to make sure that PERL_PATH set
> > to "/Program Files/Perl/perl.exe" works.  Didn't Gentoo folks see any test
> > breakage before shipping the ebuild procedure?
> The entire test suite completes fine with our
> PERL_PATH="${EPREFIX}/usr/bin/env perl" setting.
> 
> This was originally put into place because of our bug #326625 [1].
> >From that bug:
> ====
> Git does not compile if local::lib installed in user's home directory if
> 'sudo' is used to raise privileges. Local::lib exports environment
> variable PERL5_MM_OPTS, which contains string INSTALL_BASE='...'.
> Variable PREFIX is set in package's Makefile.pl. Package will not
> compile if both of these variables are set.
> ====
> (Full logs attached in the bug).
> 
> If you can suggest a better way to fix the user's bug, I'll revert the
> PERL_PATH change.
> 
> 1. https://bugs.gentoo.org/show_bug.cgi?id=326625

Robin,
What user are you running the ebuild as? All setting PERL_PATH this way
does is set Perl up to run with a modified environment (quite likely
completely trashing it in this case) which would explain why the ebuild
completes.

-- 
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59