Обсуждение: Build problem with CVS version
I'm running on Red Hat Linux 7.1 with all official updates. I have a problem or two with PostgreSQL and thought to test against the CVS version so as to avoid the suggestion (as happened recently) to "try this later version." I particularly want to install the package in some out-of-the-way place so a) It doesn't replace the existing production version b) I don't need root privilege. 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). -- 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.
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
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.
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