
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 


Tue, 27 Oct 1998 02:18:26 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
make install fails in perl5 ...
   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


Tue, 27 Oct 1998 08:46:39 -0700 (MST)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] make install fails in perl5 ...
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 clean
	cd perl5 && POSTGRES_HOME="$(POSTGRESDIR)" perl Makefile.PL
	if test -w `PERL-LIB` then
		$(MAKE) -C perl5 install
		rm -f perl5/Makefile
	else
		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

Tue, 27 Oct 1998 11:27:24 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] make install fails in perl5 ... 
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 entitled to lecture me about bloat
               than the federal government"  -- Tony Snow
==========================================================================




Tue, 27 Oct 1998 11:47:55 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] make install fails in perl5 ... 
> 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

Tue, 27 Oct 1998 17:07:01 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] make install fails in perl5 ...
> 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

Tue, 27 Oct 1998 17:23:38 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] make install fails in perl5 ...
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 entitled to lecture me about bloat
               than the federal government"  -- Tony Snow
==========================================================================




Tue, 27 Oct 1998 12:31:51 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] make install fails in perl5 ...
> 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

Tue, 27 Oct 1998 18:21:54 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] make install fails in perl5 ...
   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!)

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 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.

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

Tue, 27 Oct 1998 11:23:33 -0700 (MST)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] make install fails in perl5 ...
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

Tue, 27 Oct 1998 13:29:04 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] make install fails in perl5 ... 
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

Tue, 27 Oct 1998 13:43:52 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] make install fails in perl5 ... 
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

Tue, 27 Oct 1998 19:19:51 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] make install fails in perl5 ...

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 entitled to lecture me about bloat
               than the federal government"  -- Tony Snow
==========================================================================



Tue, 27 Oct 1998 15:12:29 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] make install fails in perl5 ...
"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.  This is just
   documentation.

2. Setting those other settings in Makefile.custom ought to be
   sufficient.  It is not, right now, because configure writes the
   values into non-makefiles that will not notice what you did in
   Makefile.custom.  This is fixable but I am leery of 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

Tue, 27 Oct 1998 15:24:26 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] make install fails in perl5 ... 
> 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

Tue, 27 Oct 1998 21:00:30 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] make install fails in perl5 ...
"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

Tue, 27 Oct 1998 17:08:21 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] make install fails in perl5 ... 
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

Tue, 27 Oct 1998 18:19:12 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] make install fails in perl5 ... 
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 bin
	INSTL_EXE_OPTS += -o pgsql -g dbadmin
	INSTL_LIB_OPTS += -o bin -g bin
	INSTL_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    | 



Thu, 29 Oct 1998 00:42:08 -0500
"Billy G. Allie" <Bill.Allie@mug.org>
Re: [HACKERS] make install fails in perl5 ... 
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    | 



Thu, 29 Oct 1998 01:10:32 -0500
"Billy G. Allie" <Bill.Allie@mug.org>
Re: [HACKERS] make install fails in perl5 ... 