Thread

1. make install fails in perl5 ...

   Marc G. Fournier <scrappy@hub.org> — 1998-10-27T06:18:26Z

   chmod 755 blib/arch/auto/Pg/Pg.so
   cp Pg.bs blib/arch/auto/Pg/Pg.bs
   chmod 644 blib/arch/auto/Pg/Pg.bs
   Manifying blib/man3/Pg.3
   mkdir /usr/local/lib/perl5/site_perl: No such file or directory at \
   	/usr/libdata/perl/5.00502/ExtUtils/Install.pm line 57
   gmake[3]: *** [pure_site_install] Error 2
   
   neat thing is that I swore that I took out perl5 altogether if the install
   wasn't being performed by root...and looking at the logs, it appears I
   did, and it got undone:
   
   -----------------------
   revision 1.214
   date: 1998/10/13 17:26:40;  author: scrappy;  state: Exp;  lines: +9 -9
   
   change configure so that if postgresql isn't being installed as root,
   do not configure in the perl5 interface.
   
   the perl5 interface needs to be installed under /usr/local/lib/perl5/*,
   which is generally owned by root.  This allows a non-root build/install
   with the only root requirement being the make/install of hte perl5
   stuff...
   -------------------------
   
   So, who took the root check out, and when, and why?  
   
   Marc G. Fournier                                
   Systems Administrator @ hub.org 
   primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
   
   
   

2. Re: [HACKERS] make install fails in perl5 ...

   Brook Milligan <brook@trillium.nmsu.edu> — 1998-10-27T15:46:39Z

      neat thing is that I swore that I took out perl5 altogether if the install
      wasn't being performed by root...and looking at the logs, it appears I
      did, and it got undone:
   
      So, who took the root check out, and when, and why?  
   
   Probably me, for a couple of reasons.
   
   - It seemed like the lack of a --with-perl option handles this.  I can
     see why we might want to verify the --with-perl option and override
     it, but what do we do if the user has perl installed in a way that
     the non-root postgresql installer can write too?  Won't this prevent
     a perfectly good installation?  For that reason, I prefer requiring
     --with-perl and accepting it.  After all, we assume all sorts of
     configure options are ok and don't override them; why is perl
     special in this regard?
   
   - It was also the case that the test involved ${WHOAMI} (I think) but
     no such variable was defined in configure.  As a result, the test
     didn't work anyway and always failed.  I pointed this out when I
     sent a patch (along with some other changes) and suggested two ways
     to go (delete the test or fix ${WHOAMI}) but I guess no one picked
     up on it and the test got deleted.
   
   I have no problem with putting it back as long as we can address the
   condition in which perl is writable by nonroot users, but it needs to
   define the variables before use.  Overall, though I feel that the
   configure options are there for the user to provide correct
   information, and that this test is not appropriate.
   
   Sorry for the confusion.
   
   Cheers,
   Brook