Обсуждение: Re: [BUGS] 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
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
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.