Обсуждение: make install fails in perl5 ...
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
neat thing is that I swore that I took out perl5 altogether if the install wasn't being performed by root...and
lookingat 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
optionand override it, but what do we do if the user has perl installed in a way that the non-root postgresql installer
canwrite too? Won't this prevent a perfectly good installation? For that reason, I prefer requiring --with-perl and
acceptingit. After all, we assume all sorts of configure options are ok and don't override them; why is perl special
inthis 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
gotdeleted.
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
The Hermit Hacker <scrappy@hub.org> writes:
> So, who took the root check out, and when, and why?
Well, I didn't do it, but I agree with whoever took it out. You cannot
test at *configure* time to see whether the invoker of configure is
root. It is not reasonable to expect people to do the configure and
build as root, even if they su to root for the install step (which
is surely the WRONG thing for a Postgres install anyway!)
I wouldn't care for a test on rootness even if it were done at the right
time, ie, install step. That's an entirely unwarranted assumption about
how people set up their file ownership. (For example, on my machine the
Perl5 tree belongs to user "gnu", not root.) A more useful test would
be whether you have write permission on the Perl5 install tree top-level
directory, but that seems to require knowing where the Perl5 install
tree *is*, a fact that's buried inside the Perl-generated makefile.
Maybe we could modify src/interfaces/Makefile along this line:
install-perl5:$(MAKE) -C perl5 cleancd perl5 && POSTGRES_HOME="$(POSTGRESDIR)" perl Makefile.PLif test -w `PERL-LIB`
then $(MAKE) -C perl5 install rm -f perl5/Makefileelse echo "Postponing Perl install, don't have permissions."
echo "To install, cd into interfaces/perl5, su to Perl" echo "file owner, and do 'make install'."fi
where PERL-LIB is some sed hackery to extract the PERL_LIB
definition from the just-built perl5/Makefile.
If you like this I will see what I can do with the idea.
We'll also need to discuss this whole business in the INSTALL
directions.
regards, tom lane
On Tue, 27 Oct 1998, Tom Lane wrote:
> The Hermit Hacker <scrappy@hub.org> writes:
> > So, who took the root check out, and when, and why?
>
> Well, I didn't do it, but I agree with whoever took it out. You cannot
> test at *configure* time to see whether the invoker of configure is
> root. It is not reasonable to expect people to do the configure and
> build as root, even if they su to root for the install step (which
> is surely the WRONG thing for a Postgres install anyway!)
Hmmm. That's how I do it, although it *is* a PITA to chown everything
to do the regression tests. It just seems odd to have one package
install this way when all the other packages I install are done from
root.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Searchable Campground Listings http://www.camping-usa.com "There is no outfit less
entitledto lecture me about bloat than the federal government" -- Tony Snow
==========================================================================
> Maybe we could modify src/interfaces/Makefile along this line:
<snip>
> We'll also need to discuss this whole business in the INSTALL
> directions.
This would be OK, but imho it would be acceptable to omit the perl
installation stuff from "make install" altogether. Then do the su to
root and install explicitly.
Or, have an "install-root" or somesuch in top level makefile to have a
catchall place for it.
So,
make install su make install-root
or something like that.
Per my recent e-mail, we've also got tcl troubles in the installation...
- Tom
> Hmmm. That's how I do it, although it *is* a PITA to chown everything
> to do the regression tests. It just seems odd to have one package
> install this way when all the other packages I install are done from
> root.
There is a security exposure to running the server as root. Other
packages can make their own security arrangements; this is ours.
My commercial Ingres package didn't run as root either.
- Tom
On Tue, 27 Oct 1998, Thomas G. Lockhart wrote:
> > Hmmm. That's how I do it, although it *is* a PITA to chown everything
> > to do the regression tests. It just seems odd to have one package
> > install this way when all the other packages I install are done from
> > root.
>
> There is a security exposure to running the server as root. Other
> packages can make their own security arrangements; this is ours.
I understand that, and I *don't* run it as root, I only install it
as root. After it's installed I chown it to postgres which is what
many other packages do. I also do everything from /usr/local/src/
instead of /usr/src. IMO, /usr/src is no place for users to be
putting or building files. It's also alot easier to back up the local
tree and be done with it. But these are just my preferences. If
someone else wants to build it in / that's their business.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Searchable Campground Listings http://www.camping-usa.com "There is no outfit less
entitledto lecture me about bloat than the federal government" -- Tony Snow
==========================================================================
> I understand that, and I *don't* run it as root, I only install it
> as root. After it's installed I chown it to postgres which is what
> many other packages do. I also do everything from /usr/local/src/
> instead of /usr/src. IMO, /usr/src is no place for users to be
> putting or building files. It's also alot easier to back up the local
> tree and be done with it. But these are just my preferences. If
> someone else wants to build it in / that's their business.
Sorry about that. I agree with you completely (I may even agree with you
more than you do! :)
I do a _lot_ of postgres building, since developing the server is one of
my hobbies. istm it is much cleaner to do everything out of
/opt/postgres, owned by postgres (as opposed to scattering things below
/, which as you point out can be a mess). I put the builds into
directories like v6.3.2 or 981014.d, then point to one with a softlink
/opt/postgres/current. Then nothing needs to happen as root for months
on end, and I can switch between versions in a minute or two if
necessary.
I'm not sure what the current thinking is on the /opt concept wrt the
newer file system conventions being negotiated between Unices...
- Tom
Well, I didn't do it, but I agree with whoever took it out. You cannot test at *configure* time to see whether the invokerof configure is root. It is not reasonable to expect people to do the configure and build as root, even if theysu to root for the install step (which is surely the WRONG thing for a Postgres install anyway!) Installing as root is fine; running as root is not. I wouldn't care for a test on rootness even if it were done at the right time, ie, install step. That's an entirely unwarrantedassumption about how people set up their file ownership. (For example, on my machine the Perl5 tree belongsto user "gnu", not root.) A more useful test would be whether you have write permission on the Perl5 install treetop-level directory, but that seems to require knowing where the Perl5 install tree *is*, a fact that's buried insidethe Perl-generated makefile. We don't really need to test this. Use --with-perl if appropriate. It will automatically find the right stuff via perl. Maybe we could modify src/interfaces/Makefile along this line: 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? Cheers, Brook
Vince Vielhaber <vev@michvhf.com> writes:
> I understand that, and I *don't* run it as root, I only install it
> as root. After it's installed I chown it to postgres which is what
> many other packages do.
I dunno, that sure seems like the hard way to me. I made
/usr/local/pgsql (which I had to do as root, since /usr/local isn't
widely writable) and chowned it to postgres. Since then, I can do
the builds, installs, and everything else as postgres.
regards, tom lane
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
Tom Lane wrote:
>
> 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...
I think you are headed in this direction, but istm that the --with-xxx
flags on configure should work for any package at any time. So someone
doing an installation can look at the "./configure --help" output and
say "I think I want those", and actually have it do the right thing,
stopping before it does the wrong thing. So, --with-perl should enable
perl building (by just setting USE_PERL or something?) but stop short of
requiring root access to the best installation location during the main
Postgres install.
I should be able to override the "--with" settings from configure with
my Makefile.custom, so I can reinstall the entire Postgres package just
by copying Makefile.custom and rerunning configure without major command
line parameters.
I suspect that the tcl/tk stuff doesn't quite work this way at the
moment, and that the perl stuff needs a bit of adjustment also. I'll
look at the ODBC stuff to get it in line if it isn't already.
- Tom
On 27-Oct-98 Tom Lane wrote:
> Vince Vielhaber <vev@michvhf.com> writes:
>> I understand that, and I *don't* run it as root, I only install it
>> as root. After it's installed I chown it to postgres which is what
>> many other packages do.
>
> I dunno, that sure seems like the hard way to me. I made
> /usr/local/pgsql (which I had to do as root, since /usr/local isn't
> widely writable) and chowned it to postgres. Since then, I can do
> the builds, installs, and everything else as postgres.
$ ./configure
$ gmake
$ sudo gmake install
Many packages build/install similarly and the makefile ensures that the
permissions and ownerships are correct. Since the postgresql makefile
doesn't do the permissions/ownerships I have to. This last part must
be what you see as "the hard way". It's what I see as odd (as I stated
earlier). That's really the only difference. If I don't do the regression
tests (and I usually don't) I don't have to bother with the permissions
on the source tree.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Searchable Campground Listings http://www.camping-usa.com "There is no outfit less
entitledto lecture me about bloat than the federal government" -- Tony Snow
==========================================================================
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> I think you are headed in this direction, but istm that the --with-xxx
> flags on configure should work for any package at any time. So someone
> doing an installation can look at the "./configure --help" output and
> say "I think I want those", and actually have it do the right thing,
> stopping before it does the wrong thing.
Right, my thoughts exactly. A reasonable person seeing the --with-perl
configure option would assume that he wants to use it, if he has Perl.
As things stand, if he's following the recommended install procedure
he probably can't use it. That's wrong.
> I should be able to override the "--with" settings from configure with
> my Makefile.custom, so I can reinstall the entire Postgres package just
> by copying Makefile.custom and rerunning configure without major command
> line parameters.
Well, that should be true as long as you also get the subsidiary
information that configure computes (locations of tclsh and friends, in
the Tcl case). It is legitimate for configure to compute those because
they are config info --- what if you have more than one version of Tcl
installed? You need to be able to specify which one to use.
We have two problems here:
1. Makefile.global ought to make clear which other settings need to be made if you want to turn on USE_TCL/USE_TK.
Thisis just documentation.
2. Setting those other settings in Makefile.custom ought to be sufficient. It is not, right now, because configure
writesthe values into non-makefiles that will not notice what you did in Makefile.custom. This is fixable but I am
leeryof trying to fix it for 6.4.
I suggest that at this late stage we ought to concentrate on making
sure that the standard configure/install procedure works smoothly.
It's too late to worry about whether people's existing Makefile.custom
will work smoothly --- and I'm not sure it's reasonable to expect a
Makefile.custom to work just because it worked with some prior version,
anyway.
> I suspect that the tcl/tk stuff doesn't quite work this way at the
> moment, and that the perl stuff needs a bit of adjustment also. I'll
> look at the ODBC stuff to get it in line if it isn't already.
I'm not touching ODBC :-).
regards, tom lane
> Well, that should be true as long as you also get the subsidiary
> information that configure computes (locations of tclsh and friends,
> in the Tcl case). It is legitimate for configure to compute those
> because they are config info --- what if you have more than one
> version of Tcl installed? You need to be able to specify which one to
> use.
Sure. But if you have only one version installed, and if things are
located in about the right places, then configure should probably get
those things done even if "--with-tcl" is not specified. It would at the
same time set "USE_TCL" to false, which could be overridden later.
> I suggest that at this late stage we ought to concentrate on making
> sure that the standard configure/install procedure works smoothly.
> It's too late to worry about whether people's existing Makefile.custom
> will work smoothly --- and I'm not sure it's reasonable to expect a
> Makefile.custom to work just because it worked with some prior
> version, anyway.
I agree, and wasn't advocating that my old Makefile.custom must continue
to work unchanged. It just helped me notice the other problems sooner by
hanging my usual, "should work easy" installation from a clean tree. And
again, it is sensitive to being a pristine installation; after the fact
it sort of repairs itself.
> > I suspect that the tcl/tk stuff doesn't quite work this way at the
> > moment, and that the perl stuff needs a bit of adjustment also. I'll
> > look at the ODBC stuff to get it in line if it isn't already.
> I'm not touching ODBC :-)
... anymore :) We currently have ODBC breakage in moving to the
Makefile.shlib. But we've already discussed fixing that. Should I just
give it a try, or do you want to see patches?
- Tom
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
>> I'm not touching ODBC :-)
> ... anymore :) We currently have ODBC breakage in moving to the
> Makefile.shlib. But we've already discussed fixing that. Should I just
> give it a try, or do you want to see patches?
Hack away. I'll try to take a look when you're done.
BTW, I believe I have fixed the tcl problem, if you care to try
that again.
regards, tom lane
OK, I've fixed the perl5 permissions problem and verified that it
actually works right :-). I didn't check in any changes to the
install.sgml file, but suggest you add something like this
right after the "make install" step:
<Step Performance="optional">
<Para>
If you used the <option>--with-perl</option> option to configure, check
the install log to see whether the Perl module was actually installed.
If you've followed our advice to make the Postgres files be owned by
an unprivileged userid, then the Perl module won't have been installed,
for lack of write privileges on the Perl library directories. You can
complete its installation, either now or later, by su'ing to the user that
does own the Perl library and doing
<ProgramListing>
$ cd /usr/src/pgsql/src/interfaces/perl5
$ gmake install
</ProgramListing>
</Para>
</Step>
regards, tom lane
Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > So, who took the root check out, and when, and why? > > Well, I didn't do it, but I agree with whoever took it out. You cannot > test at *configure* time to see whether the invoker of configure is > root. It is not reasonable to expect people to do the configure and > build as root, even if they su to root for the install step (which > is surely the WRONG thing for a Postgres install anyway!) I don't know. I install as root (so that the perl stuff will install). Of course I have the following lines in Makefile.custom: INSTLOPTS += -o bin -g binINSTL_EXE_OPTS += -o pgsql -g dbadminINSTL_LIB_OPTS += -o bin -g binINSTL_SHLIB_OPTS += -o bin-g bin so that the permissions are set the way I want them and the postgres executables are owned by the postgres user. -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com |/ |LLIE | (313) 582-1540 |
Tom Lane wrote: > "Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes: > > I think you are headed in this direction, but istm that the --with-xxx > > flags on configure should work for any package at any time. So someone > > doing an installation can look at the "./configure --help" output and > > say "I think I want those", and actually have it do the right thing, > > stopping before it does the wrong thing. > > Right, my thoughts exactly. A reasonable person seeing the --with-perl > configure option would assume that he wants to use it, if he has Perl. > As things stand, if he's following the recommended install procedure > he probably can't use it. That's wrong. > > > I should be able to override the "--with" settings from configure with > > my Makefile.custom, so I can reinstall the entire Postgres package just > > by copying Makefile.custom and rerunning configure without major command > > line parameters. Then why use configure at all? Configure is there to do a specific job. Configuring PostgreSQL to build and install on your machine. Use it to do that job. > > Well, that should be true as long as you also get the subsidiary > information that configure computes (locations of tclsh and friends, in > the Tcl case). It is legitimate for configure to compute those because > they are config info --- what if you have more than one version of Tcl > installed? You need to be able to specify which one to use. There are options in configure to let you specify the directory that contains the tclConfig.sh and tkConfig.sh. This overides the normal search sequence configure uses to find the *Config.sh files. > > We have two problems here: > > 1. Makefile.global ought to make clear which other settings need to be > made if you want to turn on USE_TCL/USE_TK. This is just > documentation. The documentation should make it clear that the Makefile.global file (or any other file that configure generates) should not be edited by hand. Configure should be used to change the configuration options! Of course, this is just my opinion, and like any other philosophical stand so generate interesting debates :-) -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com |/ |LLIE | (313) 582-1540 |