git installation (as private user) should NEVER write site_perl

git installation (as private user) should NEVER write site_perl

[Randal L. Schwartz]

I tried to install git on a system where I was a normal user.  Of course,
this step fails:

     Installing /usr/perl5/site_perl/5.6.1/Error.pm
     Installing /usr/perl5/site_perl/5.6.1/Git.pm

But on a larger level, this should never have even been attempted, whether I
was a private user OR the box administrator.  The git installation should NOT
be installing things into the site_perl directory, which is owned by the CPAN
installation tools, and also by the various packaging tools, and is also seen
by non-git users of Perl on the machine.  (It would be bad to have two
different versions of Error.pm now being seen by all users.)

If git wants to add local Perl modules, they belong in ${prefix}/lib/perl/
or something, with the appropriate "use lib" added to the Perl scripts.

No patches attached, but this is a showstopper for my client, and a bit of a
shocker for me.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: git installation (as private user) should NEVER write site_perl

[Erik Mouw]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

On Tue, Feb 20, 2007 at 09:18:15AM -0800, Randal L. Schwartz wrote:
> I tried to install git on a system where I was a normal user.  Of course,
> this step fails:
> 
>      Installing /usr/perl5/site_perl/5.6.1/Error.pm
>      Installing /usr/perl5/site_perl/5.6.1/Git.pm

It gets installed in ~/share/perl/5.8.4/ when I compile as a normal
user (git-1.5.0.1):

Installing /home/erik/share/perl/5.8.4/Error.pm
Installing /home/erik/share/perl/5.8.4/Git.pm
Installing /home/erik/man/man3/private-Error.3pm
Installing /home/erik/man/man3/Git.3pm


Erik

-- 
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: git installation (as private user) should NEVER write site_perl

[Randal L. Schwartz]

>>>>> "Erik" == Erik Mouw <mouw@nl.linux.org> writes:

Erik> On Tue, Feb 20, 2007 at 09:18:15AM -0800, Randal L. Schwartz wrote:
>> I tried to install git on a system where I was a normal user.  Of course,
>> this step fails:
>> 
>> Installing /usr/perl5/site_perl/5.6.1/Error.pm
>> Installing /usr/perl5/site_perl/5.6.1/Git.pm

Erik> It gets installed in ~/share/perl/5.8.4/ when I compile as a normal
Erik> user (git-1.5.0.1):

Erik> Installing /home/erik/share/perl/5.8.4/Error.pm
Erik> Installing /home/erik/share/perl/5.8.4/Git.pm
Erik> Installing /home/erik/man/man3/private-Error.3pm
Erik> Installing /home/erik/man/man3/Git.3pm

Is that a personally-installed Perl though?  Those paths look suspicious.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: git installation (as private user) should NEVER write site_perl

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

Randal> If git wants to add local Perl modules, they belong in
Randal> ${prefix}/lib/perl/ or something, with the appropriate "use lib" added
Randal> to the Perl scripts.

>From a bit further research, it looks like git prefers installing git-only
Perl modules using the standard MakeMaker, which of course will try to
install them in site_lib.

Oddly enough, if I define NO_PERL_MAKEMAKER, I get the behavior I want.

I suggest that NO_PERL_MAKEMAKER is the *only* correct behavior in this case,
so I propose that the code be made unconditional, and the Makemaker stuff be
pulled out.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: git installation (as private user) should NEVER write site_perl

[Erik Mouw]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

On Tue, Feb 20, 2007 at 09:57:46AM -0800, Randal L. Schwartz wrote:
> >>>>> "Erik" == Erik Mouw <mouw@nl.linux.org> writes:
> 
> Erik> On Tue, Feb 20, 2007 at 09:18:15AM -0800, Randal L. Schwartz wrote:
> >> I tried to install git on a system where I was a normal user.  Of course,
> >> this step fails:
> >> 
> >> Installing /usr/perl5/site_perl/5.6.1/Error.pm
> >> Installing /usr/perl5/site_perl/5.6.1/Git.pm
> 
> Erik> It gets installed in ~/share/perl/5.8.4/ when I compile as a normal
> Erik> user (git-1.5.0.1):
> 
> Erik> Installing /home/erik/share/perl/5.8.4/Error.pm
> Erik> Installing /home/erik/share/perl/5.8.4/Git.pm
> Erik> Installing /home/erik/man/man3/private-Error.3pm
> Erik> Installing /home/erik/man/man3/Git.3pm
> 
> Is that a personally-installed Perl though?  Those paths look suspicious.

No, just standard Debian stable packages:

  erik@zurix:~> which perl
  /usr/bin/perl
  erik@zurix:~> dpkg -S /usr/bin/perl
  perl-base: /usr/bin/perl
  perl-base: /usr/bin/perl
  erik@zurix:~> dpkg -l perl-base
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
  |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
  ||/ Name           Version        Description
  +++-==============-==============-============================================
  ii  perl-base      5.8.4-8sarge5  The Pathologically Eclectic Rubbish Lister

Git is installed in my home directory:

  erik@zurix:~ > which git
  /home/erik/bin/git


Erik

-- 
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: git installation (as private user) should NEVER write site_perl

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Erik" == Erik Mouw <mouw@nl.linux.org> writes:
>
> Erik> On Tue, Feb 20, 2007 at 09:18:15AM -0800, Randal L. Schwartz wrote:
>>> I tried to install git on a system where I was a normal user.  Of course,
>>> this step fails:
>>> 
>>> Installing /usr/perl5/site_perl/5.6.1/Error.pm
>>> Installing /usr/perl5/site_perl/5.6.1/Git.pm
>
> Erik> It gets installed in ~/share/perl/5.8.4/ when I compile as a normal
> Erik> user (git-1.5.0.1):
>
> Erik> Installing /home/erik/share/perl/5.8.4/Error.pm
> Erik> Installing /home/erik/share/perl/5.8.4/Git.pm
> Erik> Installing /home/erik/man/man3/private-Error.3pm
> Erik> Installing /home/erik/man/man3/Git.3pm
>
> Is that a personally-installed Perl though?  Those paths look suspicious.

Actually that is what I get on my Debian box (Perl is from
distribution).  I build with prefix=$HOME/git-next and get

        $ ls -lR ~/git-next/*/perl
        /home/junio/git-next/lib/perl:
        total 12
        drwxrwsr-x 3 junio junio 4096 2007-02-20 10:17 ./
        drwxrwsr-x 3 junio junio 4096 2007-02-20 10:17 ../
        drwxrwsr-x 3 junio junio 4096 2007-02-20 10:17 5.8.8/

        /home/junio/git-next/lib/perl/5.8.8:
        total 16
        drwxrwsr-x 3 junio junio 4096 2007-02-20 10:17 ./
        drwxrwsr-x 3 junio junio 4096 2007-02-20 10:17 ../
        drwxr-sr-x 3 junio junio 4096 2007-02-20 10:17 auto/
        -rw-rw-r-- 1 junio junio  221 2007-02-20 10:17 perllocal.pod

        /home/junio/git-next/lib/perl/5.8.8/auto:
        total 12
        drwxr-sr-x 3 junio junio 4096 2007-02-20 10:17 ./
        drwxrwsr-x 3 junio junio 4096 2007-02-20 10:17 ../
        drwxr-sr-x 2 junio junio 4096 2007-02-20 10:17 Git/

        /home/junio/git-next/lib/perl/5.8.8/auto/Git:
        total 12
        drwxr-sr-x 2 junio junio 4096 2007-02-20 10:17 ./
        drwxr-sr-x 3 junio junio 4096 2007-02-20 10:17 ../
        -rw-rw-r-- 1 junio junio   83 2007-02-20 10:17 .packlist

        /home/junio/git-next/share/perl:
        total 12
        drwxrwsr-x 3 junio junio 4096 2006-11-08 23:25 ./
        drwxr-sr-x 4 junio junio 4096 2006-11-08 23:25 ../
        drwxrwsr-x 2 junio junio 4096 2007-02-03 22:18 5.8.8/

        /home/junio/git-next/share/perl/5.8.8:
        total 32
        drwxrwsr-x 2 junio junio  4096 2007-02-03 22:18 ./
        drwxrwsr-x 3 junio junio  4096 2006-11-08 23:25 ../
        -r--r--r-- 1 junio junio 22332 2007-02-03 22:15 Git.pm

I have /usr/share/perl5/Error.pm that is packaged liberror-perl
from the distro.

Re: git installation (as private user) should NEVER write site_perl

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> If git wants to add local Perl modules, they belong in
Randal> ${prefix}/lib/perl/ or something, with the appropriate "use lib" added
Randal> to the Perl scripts.

Randal> Oddly enough, if I define NO_PERL_MAKEMAKER, I get the behavior I want.

Randal> I suggest that NO_PERL_MAKEMAKER is the *only* correct behavior in this case,
Randal> so I propose that the code be made unconditional, and the Makemaker stuff be
Randal> pulled out.

So, something spookier is happening on this solaris box then.  I can
see that if MakeMaker is used, the Makefile.PL is referring to INST_LIBDIR
which should indeed be private inside git's area.  And in fact, I can
verify on my laptop that Git.pm was indeed installed into /opt/git/lib/site_perl/5.8.8/

I don't know why this isn't working on solaris. :( It might be that the
MakeMaker is too old, and doesn't respect the same prefix elements.

Call off the hounds... I can locally work around it by setting
NO_PERL_MAKEMAKER, and suspect I won't have anything further to contribute to
the core on this matter.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!