{"thread":{"id":"27282","subject":"Question about PERL_PATH","startedAt":"2011-05-06T13:30:44Z","lastAt":"2011-05-09T14:49:55Z","messageCount":7,"participants":["Ian Abbott","Michael J Gruber","Junio C Hamano","Robin H. Johnson","Jeff King","Drew Northup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"167247","messageId":"4DC3F804.3080205@mev.co.uk","threadId":"27282","inReplyTo":null,"subject":"Question about PERL_PATH","fromName":"Ian Abbott","fromEmail":"abbotti@mev.co.uk","sentAt":"2011-05-06T13:30:44Z","receivedAt":"2011-05-06T13:30:44Z","isPatch":false,"sender":{"key":"abbotti@mev.co.uk","avatar":null},"body":"The Gentoo ebuilds for git have started invoking 'make' with the option\n'PERL_PATH=/usr/bin/env perl'. This doesn't seem to cause any problems\nexcept when running git instaweb, which outputs an error similar to the\nfollowing:\n\n/usr/libexec/git-core/git-instaweb: line 135: /usr/bin/env perl: No such\nfile or directory\n\nThere is an easy workaround, which is to modify the invocation of perl\nin the httpd_is_ready() function in the git-instaweb shell script. It\ncurrently invokes perl as \"$PERL\" (with the quotes). Removing the\nquotes makes it work.\n\nMy question is, should git support Gentoo's unusual setting of PERL_PATH\nas a multi-word command, or should Gentoo patch around the problem they\nhave created with git-instaweb themselves?\n\nThere is one other place where $PERL is used in git-instaweb and that is\nin the mongoose_conf() function. It has a heredoc that puts the\nfollowing line in the httpd.conf file (subject to shell variable expansion):\n\ncgi_interp\t$PERL\n\nFor Gentoo, that would get expanded to the following:\n\ncgi_interp\t/usr/bin/env perl\n\nI don't know if Mongoose would choke on this or not.\n\n-- \n-=( Ian Abbott @ MEV Ltd. E-mail: )=-\n-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-\n"},{"id":"167256","messageId":"4DC41A3D.10104@drmicha.warpmail.net","threadId":"27282","inReplyTo":"4DC3F804.3080205@mev.co.uk","subject":"Re: Question about PERL_PATH","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-05-06T15:56:45Z","receivedAt":"2011-05-06T15:56:45Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Ian Abbott venit, vidit, dixit 06.05.2011 15:30:\n> The Gentoo ebuilds for git have started invoking 'make' with the option\n> 'PERL_PATH=/usr/bin/env perl'. This doesn't seem to cause any problems\n> except when running git instaweb, which outputs an error similar to the\n> following:\n\nWell, it means that all our perl scripts are run with the perl which is\nthe first in PATH at run time (for the user running it), which may or\nmay not be the one which is first in PATH at build or test time (for the\nuser running that).\n\nOf course there's no problem when they are the same.\n\n> /usr/libexec/git-core/git-instaweb: line 135: /usr/bin/env perl: No such\n> file or directory\n> \n> There is an easy workaround, which is to modify the invocation of perl\n> in the httpd_is_ready() function in the git-instaweb shell script. It\n> currently invokes perl as \"$PERL\" (with the quotes). Removing the\n> quotes makes it work.\n> \n> My question is, should git support Gentoo's unusual setting of PERL_PATH\n> as a multi-word command, or should Gentoo patch around the problem they\n> have created with git-instaweb themselves?\n> \n> There is one other place where $PERL is used in git-instaweb and that is\n> in the mongoose_conf() function. It has a heredoc that puts the\n> following line in the httpd.conf file (subject to shell variable expansion):\n> \n> cgi_interp\t$PERL\n> \n> For Gentoo, that would get expanded to the following:\n> \n> cgi_interp\t/usr/bin/env perl\n> \n> I don't know if Mongoose would choke on this or not.\n\nFor a system wide installed package, it just seems like a crazy idea to\npackage it in a way which makes it depend on the contents of users'\n$HOME/bin and such. What kind of packaging is that? I mean, package git\ndepends on package perl, but then leave the meaning of \"perl\" at the\nusers' discretion and mercy...\n\nMichael\n"},{"id":"167258","messageId":"7v7ha33jd7.fsf@alter.siamese.dyndns.org","threadId":"27282","inReplyTo":"4DC3F804.3080205@mev.co.uk","subject":"Re: Question about PERL_PATH","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-06T16:05:08Z","receivedAt":"2011-05-06T16:05:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ian Abbott writes:\n\n> The Gentoo ebuilds for git have started invoking 'make' with the option\n> 'PERL_PATH=/usr/bin/env perl'. This doesn't seem to cause any problems\n> except when running git instaweb, which outputs an error similar to the\n> following:\n>\n> /usr/libexec/git-core/git-instaweb: line 135: /usr/bin/env perl: No such\n> file or directory\n\nThe variable is not PERL_COMMAND_LINE, but is PERL_PATH, so I think it\nshould expects the path to the program.\n\nOur testsuite also rely on it being the path to the program by enclosing\nthe reference to it inside double quotes, to make sure that PERL_PATH set\nto \"/Program Files/Perl/perl.exe\" works. Didn't Gentoo folks see any test\nbreakage before shipping the ebuild procedure?\n"},{"id":"167261","messageId":"4DC424EB.6000107@mev.co.uk","threadId":"27282","inReplyTo":"7v7ha33jd7.fsf@alter.siamese.dyndns.org","subject":"Re: Question about PERL_PATH","fromName":"Ian Abbott","fromEmail":"abbotti@mev.co.uk","sentAt":"2011-05-06T16:42:19Z","receivedAt":"2011-05-06T16:42:19Z","isPatch":false,"sender":{"key":"abbotti@mev.co.uk","avatar":null},"body":"On 06/05/11 17:05, Junio C Hamano wrote:\n> Ian Abbott writes:\n> \n>> The Gentoo ebuilds for git have started invoking 'make' with the option\n>> 'PERL_PATH=/usr/bin/env perl'. This doesn't seem to cause any problems\n>> except when running git instaweb, which outputs an error similar to the\n>> following:\n>>\n>> /usr/libexec/git-core/git-instaweb: line 135: /usr/bin/env perl: No such\n>> file or directory\n> \n> The variable is not PERL_COMMAND_LINE, but is PERL_PATH, so I think it\n> should expects the path to the program.\n> \n> Our testsuite also rely on it being the path to the program by enclosing\n> the reference to it inside double quotes, to make sure that PERL_PATH set\n> to \"/Program Files/Perl/perl.exe\" works. Didn't Gentoo folks see any test\n> breakage before shipping the ebuild procedure?\n\nBoth you and Michael make excellent points and I've submitted a Gentoo\nbug report mentioning this thread, so we'll see what happens!\n\nhttp://bugs.gentoo.org/show_bug.cgi?id=366241\n\n-- \n-=( Ian Abbott @ MEV Ltd. E-mail: )=-\n-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-\n"},{"id":"167330","messageId":"robbat2-20110507T174237-068953557Z@orbis-terrarum.net","threadId":"27282","inReplyTo":"7v7ha33jd7.fsf@alter.siamese.dyndns.org","subject":"Re: Question about PERL_PATH","fromName":"Robin H. Johnson","fromEmail":"robbat2@gentoo.org","sentAt":"2011-05-07T18:02:48Z","receivedAt":"2011-05-07T18:02:48Z","isPatch":false,"sender":{"key":"robbat2@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/373898?v=4"},"body":"On Fri, May 06, 2011 at 09:05:08AM -0700, Junio C Hamano wrote:\n> The variable is not PERL_COMMAND_LINE, but is PERL_PATH, so I think it\n> should expects the path to the program.\n> \n> Our testsuite also rely on it being the path to the program by enclosing\n> the reference to it inside double quotes, to make sure that PERL_PATH set\n> to \"/Program Files/Perl/perl.exe\" works. Didn't Gentoo folks see any test\n> breakage before shipping the ebuild procedure?\nThe entire test suite completes fine with our\nPERL_PATH=\"${EPREFIX}/usr/bin/env perl\" setting.\n\nThis was originally put into place because of our bug #326625 [1].\nFrom that bug:\n====\nGit does not compile if local::lib installed in user's home directory if\n'sudo' is used to raise privileges. Local::lib exports environment\nvariable PERL5_MM_OPTS, which contains string INSTALL_BASE='...'.\nVariable PREFIX is set in package's Makefile.pl. Package will not\ncompile if both of these variables are set.\n====\n(Full logs attached in the bug).\n\nIf you can suggest a better way to fix the user's bug, I'll revert the\nPERL_PATH change.\n\n1. https://bugs.gentoo.org/show_bug.cgi?id=326625\n\n-- \nRobin Hugh Johnson\nGentoo Linux: Developer, Trustee & Infrastructure Lead\nE-Mail : robbat2@gentoo.org\nGnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85\n"},{"id":"167341","messageId":"20110508001326.GA13282@sigill.intra.peff.net","threadId":"27282","inReplyTo":"robbat2-20110507T174237-068953557Z@orbis-terrarum.net","subject":"Re: Question about PERL_PATH","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-08T00:13:26Z","receivedAt":"2011-05-08T00:13:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 07, 2011 at 06:02:48PM +0000, Robin H. Johnson wrote:\n\n> On Fri, May 06, 2011 at 09:05:08AM -0700, Junio C Hamano wrote:\n> > The variable is not PERL_COMMAND_LINE, but is PERL_PATH, so I think it\n> > should expects the path to the program.\n> > \n> > Our testsuite also rely on it being the path to the program by enclosing\n> > the reference to it inside double quotes, to make sure that PERL_PATH set\n> > to \"/Program Files/Perl/perl.exe\" works. Didn't Gentoo folks see any test\n> > breakage before shipping the ebuild procedure?\n> The entire test suite completes fine with our\n> PERL_PATH=\"${EPREFIX}/usr/bin/env perl\" setting.\n\nThis is more luck than anything. For example, you are skipping all of\nthe perl tests (t9700) and all of the git-svn tests (t91*), because they\nboth try do something like:\n\n if ! \"$PERL_PATH\" -e \"use SomeModule\"; then\n skip_all=\"You don't have SomeModule installed\"\n fi\n\nSo you are skipping many tests accidentally, and it is only luck that\nall such uses are currently tests that handle a broken \"$PERL_PATH\" in\nthis way. It is entirely likely that this usage may end up causing a\ntest suite failure at some point in the future.\n\nIf we want to support this use of env/, we need to provide separate\nMakefile variables for \"what goes at the top of a perl script\" and \"what\nwe use to run perl\".\n\n> This was originally put into place because of our bug #326625 [1].\n> From that bug:\n> ====\n> Git does not compile if local::lib installed in user's home directory if\n> 'sudo' is used to raise privileges. Local::lib exports environment\n> variable PERL5_MM_OPTS, which contains string INSTALL_BASE='...'.\n> Variable PREFIX is set in package's Makefile.pl. Package will not\n> compile if both of these variables are set.\n> ====\n> (Full logs attached in the bug).\n> \n> If you can suggest a better way to fix the user's bug, I'll revert the\n> PERL_PATH change.\n\nIt looks like we auto-build the perl bits of the Makefile by calling:\n\n $(PERL_PATH) Makefile.PL PREFIX=$(prefix) INSTALL_BASE=''\n\nwhich seems to me like it should override local::lib's INSTALL_BASE\n(which also doesn't seem ideal, but I wouldn't expect it to cause this\nerror). But surely the solution involves changing this line in\nperl/Makefile to handle the local::lib case?\n\nI also don't see how this is git-specific. From my reading of the bug\nreport, local::lib will fail to work any time the user does:\n\n perl Makefile.PL PREFIX=anything\n\nwhich seems odd. Wouldn't other packages be running into this problem,\nthen, too (i.e., anything which has a little bit of perl and\nautomagically runs MakeMaker on behalf of the user)?\n\n-Peff\n"},{"id":"167503","messageId":"1304952595.19245.9.camel@drew-northup.unet.maine.edu","threadId":"27282","inReplyTo":"robbat2-20110507T174237-068953557Z@orbis-terrarum.net","subject":"Re: Question about PERL_PATH","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-05-09T14:49:55Z","receivedAt":"2011-05-09T14:49:55Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Sat, 2011-05-07 at 18:02 +0000, Robin H. Johnson wrote:\n> On Fri, May 06, 2011 at 09:05:08AM -0700, Junio C Hamano wrote:\n> > The variable is not PERL_COMMAND_LINE, but is PERL_PATH, so I think it\n> > should expects the path to the program.\n> > \n> > Our testsuite also rely on it being the path to the program by enclosing\n> > the reference to it inside double quotes, to make sure that PERL_PATH set\n> > to \"/Program Files/Perl/perl.exe\" works. Didn't Gentoo folks see any test\n> > breakage before shipping the ebuild procedure?\n> The entire test suite completes fine with our\n> PERL_PATH=\"${EPREFIX}/usr/bin/env perl\" setting.\n> \n> This was originally put into place because of our bug #326625 [1].\n> >From that bug:\n> ====\n> Git does not compile if local::lib installed in user's home directory if\n> 'sudo' is used to raise privileges. Local::lib exports environment\n> variable PERL5_MM_OPTS, which contains string INSTALL_BASE='...'.\n> Variable PREFIX is set in package's Makefile.pl. Package will not\n> compile if both of these variables are set.\n> ====\n> (Full logs attached in the bug).\n> \n> If you can suggest a better way to fix the user's bug, I'll revert the\n> PERL_PATH change.\n> \n> 1. https://bugs.gentoo.org/show_bug.cgi?id=326625\n\nRobin,\nWhat user are you running the ebuild as? All setting PERL_PATH this way\ndoes is set Perl up to run with a modified environment (quite likely\ncompletely trashing it in this case) which would explain why the ebuild\ncompletes.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"}]}