Brook Milligan <brook@trillium.NMSU.Edu> writes:
> No. Why can't we rely on people using --with-perl correctly to
> specify if they do or do not want perl. The whole point of the recent
> run-around with the perl Makefile stuff was so that postgres could be
> installed without perl and later someone could do the normal perl
> install in that directory. You get this functionality by running
> configure without the --with-perl option and all is well.
> What am I missing?
What you're missing is that that renders configure --with-perl
practically useless.
If you say --with-perl, that not only builds the perl module along with
postgres (cool, especially if we ever arrange for pre-install testing),
but also tries to *install* it along with postgres (not so cool).
The permissions required to do the install may be different for postgres
itself and a perl module. They *are* different if you follow the
recommended install procedure of making postgres be an unprivileged
user.
I'm with Marc on this one, actually; I've been hacking around this
permissions problem by chmod'ing my perl tree when I was about to run
a postgres install, and that's not cool. Becoming root in order to
install is a band-aid, not a proper solution.
After I sent off my previous message I realized that it still wasn't
quite right; the install-perl Makefile rule should rebuild the perl
module with "make all" even if it doesn't have permissions to install
the result. That way, if I come along and su to the Perl file owner
and do make install in interfaces/perl5, I don't need write permission
on the perl module files (which are still postgres's). In a setup like
mine, where the Perl file owner is not root but another unprivileged
account much like postgres, it should be possible to do all these
installs without ever becoming root (except to make the initial
/usr/local/pgsql directory).
I'll fix this this afternoon, unless I hear a better objection...
regards, tom lane