Thread: Re: [BUGS] Build problem with CVS version

Re: [BUGS] Build problem with CVS version

From
Peter Eisentraut
Date:
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



Re: [BUGS] Build problem with CVS version

From
Tom Lane
Date:
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


Re: [BUGS] Build problem with CVS version

From
Peter Eisentraut
Date:
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



Re: [BUGS] Build problem with CVS version

From
John Summerfield
Date:
> 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
installedinto 
 
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.





Re: [BUGS] Build problem with CVS version

From
Lamar Owen
Date:
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


Re: [BUGS] Build problem with CVS version

From
Peter Eisentraut
Date:
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



Re: [BUGS] Build problem with CVS version

From
John Summerfield
Date:
> 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.