Build problem with CVS version

John Summerfield writes:

To my dismay some components don't honour the "--prefix=/tmp/postgresql"
specification and try to install in some other location.

I'd much prefer for the perl and python components to install into the
location I specified, and to leave me to discuss with Perl and Python
the question of how to make sure I get the right versions (or even
better, offer a handy hint).

This is a very valid concern, and it's been bugging us, too. The problem
is that by default, the majority of users would probably want the Perl and
Python modules to be put in the default place where they're easy to find
for the interpreter. (This is pure speculation. Personally, I certainly
wouldn't do this, in the same way as I don't install libraries in /usr/lib
because it makes it easier for the linker to find.)

What we probably want is some configure switch that switches between the
current behaviour and the behaviour you want.

Incidentally, some work toward this goal has already been done in the CVS
tip. Basically, all I was missing is a good name for the option.

For you to proceed you could try the following (completely untested):

# for local Python install
make install python_moduledir='$(pkglibdir)' python_moduleexecdir='$(pkglibdir)'
# (yes, single quotes)

# for local Perl install
make install mysterious_feature=yes
# (seriously)

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Peter Eisentraut <peter_e@gmx.net> writes:

This is a very valid concern, and it's been bugging us, too. The problem
is that by default, the majority of users would probably want the Perl and
Python modules to be put in the default place where they're easy to find
for the interpreter. (This is pure speculation. Personally, I certainly
wouldn't do this, in the same way as I don't install libraries in /usr/lib
because it makes it easier for the linker to find.)

I agree that that's the right place to put the perl & python modules
when doing a pure-default configure: it's reasonable to assume we are
installing a production system, and so we should install these modules
in the default places. But it's a lot harder to make that argument when
doing a configure with a non-default --prefix: we may well be building a
playpen installation. In any case there should be a way to suppress
automatic installation of these modules.

What we probably want is some configure switch that switches between the
current behaviour and the behaviour you want.

I'd suggest --prefix-like options to determine installation locations
for the perl and python modules, plus options on the order of
--no-install-perl (ie, build it, but don't install it).

regards, tom lane

Tom Lane writes:

What we probably want is some configure switch that switches between the
current behaviour and the behaviour you want.

I'd suggest --prefix-like options to determine installation locations
for the perl and python modules,

Basically, I was envisioning some option like

--enable-local-installation-layout
--enable-playpen-installation

just something, um, better. (If we name them --with-perldir, then 51% of
the users will think that's the location where Perl itself is installed.)

Actually, if you do opt for the "playpen" version then the actual choice
of installation directory shouldn't be so interesting. The only
reasonable place is ${libdir}/postgresql, unless you want to make up your
own file system standard.

plus options on the order of --no-install-perl (ie, build it, but
don't install it).

This is currently the default behaviour, if you recall. ;-)

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Tom Lane writes:

What we probably want is some configure switch that switches between the
current behaviour and the behaviour you want.

I'd suggest --prefix-like options to determine installation locations
for the perl and python modules,

Basically, I was envisioning some option like

--enable-local-installation-layout
--enable-playpen-installation

I'd point out this from the INSTALL document:
--prefix=PREFIX

Install all files under the directory PREFIX instead of
/usr/local/pgsql. The actual files will be installed into
various
subdirectories; no files will ever be installed directly into
the
PREFIX directory.

If you have special needs, you can also customize the
individual
subdirectories with the following options.

This is entirely consistent with the way other software that uses the
same configuration procedure.

I contend that if a user wants different behaviour the onus is on the
user to specify that.

I've no argument with those who'd make it easy to specify that
different behaviour with, perhaps, --disable-perl-install as a
configure option.

Installing everything under --prefix (as the document says) would also
help package builders; the current rpm looks pretty horrible (and
that's why I didn't pursue THAT path).

just something, um, better. (If we name them --with-perldir, then 51% of
the users will think that's the location where Perl itself is installed.)

Actually, if you do opt for the "playpen" version then the actual choice
of installation directory shouldn't be so interesting. The only
reasonable place is ${libdir}/postgresql, unless you want to make up your
own file system standard.

plus options on the order of --no-install-perl (ie, build it, but
don't install it).

This is currently the default behaviour, if you recall. ;-)

Actually the reason it gave for not installing the perl bits is that I
didn't have the authority. It would have been completely happy if I'd
been root.

And I wouldn't have.

--
Cheers
John Summerfield

Microsoft's most solid OS: http://www.geocities.com/rcwoolley/

Note: mail delivered to me is deemed to be intended for me, for my
disposition.

On Thursday 06 September 2001 07:46 pm, John Summerfield wrote:

I'd point out this from the INSTALL document:
--prefix=PREFIX

[snip]

Installing everything under --prefix (as the document says) would also
help package builders; the current rpm looks pretty horrible (and
that's why I didn't pursue THAT path).

Blame the Linux Filesystem Hierarchy Standard and the Linux Standards Base
for the directory structure of the RPMset. Things have to be in specified
locations to be FHS compliant -- and the current RPMset is, to the best of my
knowledge, FHS compliant.

Horrible looking is in the eye of the beholder, BTW. Some think that a
separate prefix for each software package looks horrible and that the
intermingled nature of the FHS looks cleaner (which it does from a PATH point
of view, for sure).

It just comes down to the OS philosophy you deal with. BSD ports, for
instance, has a very different package philosophy from Solaris, which is
different yet from Domain/OS, which is different yet from the LSB.
PostgreSQL is very BSDish -- and, while I have to cut cartwheels to finagle
it into an LSB mold, being BSDish is not a bad thing. Neither is being
LSBish -- both have their place. The is no One True Filesystem spec...

As to the can't install perl client issue, the install can fail, even if done
as root, if you are building for installation at some other location in the
filesystem.

The perl client install phase fails every time I build an RPMset -- the RPM
spec file has to go through some steps to make it work.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

John Summerfield writes:

I'd point out this from the INSTALL document:
--prefix=PREFIX

Install all files under the directory PREFIX instead of
/usr/local/pgsql. The actual files will be installed into various
subdirectories; no files will ever be installed directly into the
PREFIX directory.

If you have special needs, you can also customize the individual
subdirectories with the following options.

But there are also exceptions listed at --with-perl and --with-python.

This is entirely consistent with the way other software that uses the
same configuration procedure.

I am not aware of a package that installs general-purpose Perl/Python
modules as well as items from outside of those environments.

I contend that if a user wants different behaviour the onus is on the
user to specify that.

You're probably right, but I suspect that the majority of users rightly
expect the Perl module to go where Perl modules usually go. This wouldn't
be such an interesting question if Perl provided a way to add to the
module search path (cf. LD_LIBRARY_PATH and such), but to my knowledge
there isn't a generally accepted one, so this issue would introduce an
annoyance for users.

Surely the current behaviour is an annoyance too, making the whole issue a
rather unpleasant subject. ;-)

Well, as soon as I come up with a name for the install-where-I-tell-you-to
option, I'll implement it.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

John Summerfield writes:

I'd point out this from the INSTALL document:
--prefix=PREFIX

Install all files under the directory PREFIX instead of
/usr/local/pgsql. The actual files will be installed into various
subdirectories; no files will ever be installed directly into the
PREFIX directory.

If you have special needs, you can also customize the individual
subdirectories with the following options.

But there are also exceptions listed at --with-perl and --with-python.

This is entirely consistent with the way other software that uses the
same configuration procedure.

I am not aware of a package that installs general-purpose Perl/Python
modules as well as items from outside of those environments.

I contend that if a user wants different behaviour the onus is on the
user to specify that.

You're probably right, but I suspect that the majority of users rightly
expect the Perl module to go where Perl modules usually go. This wouldn't

that isn't reasonable if the installer's not root, and I wasn't, for
the precise reason I didn't want to update the system.

be such an interesting question if Perl provided a way to add to the
module search path (cf. LD_LIBRARY_PATH and such), but to my knowledge
there isn't a generally accepted one, so this issue would introduce an
annoyance for users.

from 'man perlrun'
PERL5LIB A colon-separated list of directories in which to look
for Perl library files
before looking in the standard library and the
current directory. Any architec-
ture-specific directories under the specified
locations are automatically
included if they exist. If PERL5LIB is not defined,
PERLLIB is used.

When running taint checks (either because the
program was running setuid or set-
gid, or the -T switch was used), neither variable is
used. The program should
instead say:

There are several other environment variables.

Surely the current behaviour is an annoyance too, making the whole issue a
rather unpleasant subject. ;-)

Well, as soon as I come up with a name for the install-where-I-tell-you-to
option, I'll implement it.

The current behaviour makes it difficult to have two versions on one
computer.
--
Cheers
John Summerfield

Microsoft's most solid OS: http://www.geocities.com/rcwoolley/

Note: mail delivered to me is deemed to be intended for me, for my
disposition.