Thread: Building Postgres
OK, so I'm working on updating the RH Linux rpm of Postgres to our new release. And so I'll have to figure out how to *really* install all of the Postgres components to make this work. Anyway, I've already asked about the python installation procedure: thanks for the tips and I'll try it out soon. In the meantime, I've got other nagging problems/issues/questions. Here is one: On my linux box, psql has always built as a static app, not using the libpq.so shared library. There seem to be two issues: - libpq.so has not been installed at the time psql is built, so the shared library is not available - the link step for psql points at the libpq source directory, which contains only the .a library, not the sharable library since that is built on the fly during the library installation. I can see how to modify the psql makefile to get a version using shared libraries, but istm that one would really like to phase the installation so that libraries are actually installed before apps need to be linked. Should we just build the sharable library during the "make all" rather than the "make install"? Or perhaps it would be better to install the library(ies) and then move on to building apps. Comments? -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
> - the link step for psql points at the libpq source directory, which
> contains only the .a library, not the sharable library since that is
> built on the fly during the library installation.
> Comments?
I am wrong about this one (the shared library *is* built during "make
all"), but am still looking for suggestions for the right way to phase
the building for an installation. Do other platforms have statically
built apps too?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I am wrong about this one (the shared library *is* built during "make
> all"), but am still looking for suggestions for the right way to phase
> the building for an installation. Do other platforms have statically
> built apps too?
The only really good, cross-platform solution that I know about is to
start using GNU "libtool" to manage the construction of the shared
libraries and the applications that depend on them. There are enough
different ways to handle (or mishandle) shared libs on different Unix
platforms that I do not think it a good use of our time to try to solve
the problem piecemeal; we'd just be reinventing libtool, probably not
very well.
I have it on my to-do list to incorporate libtool into the Postgres
build system, but I have been putting off actually doing anything,
because I don't think that the current release of libtool is quite there
on supporting multiple levels of library dependencies (pgtclsh depends
on libpgtcl.so depends on libpq.so...). This feature was originally
promised for libtool 1.3 but has been put off to 1.4.
In the meantime, I'd suggest living with the static-library build, or
else installing libpq and then repeating the build step for psql...
regards, tom lane
> In the meantime, I'd suggest living with the static-library build, or
> else installing libpq and then repeating the build step for psql...
For v6.5, I think I'm going to do the phased build (the "repeating"
option). But I'm pretty sure I'll do it with a patch to the top level
Makefile, and will suggest it as a feature for v6.6, so this phasing
can be repeated.
It's an interesting problem, since preparing an rpm involves building
the entire app, and then copying pieces like libraries into the binary
rpm file. For the basic pieces this looks fairly straightforward,
except for the phasing problem mentioned above, but for some packages
like perl and pythong it apparently involves modifying configuration
files in the perl or python distribution itself. Hopefully there will
be a reasonable way to do it...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> For v6.5, I think I'm going to do the phased build (the "repeating"
> option).
OK, I think I've got a good start at a Postgres-6.5 rpm set. It will
have the apps using shared libraries, rather than static links. It
includes more interfaces than past rpms, including ODBC, and I've
separated out the language-specific features into separate rpms (e.g.
the tcl interfaces are in postgres-tcl-6.5-1.rpm).
I'm now trying to package the perl (and next, python) interfaces. Can
someone with perl installation experience give me some hints on what
actually needs to be installed and how it has to happen?
The Postgres source tree uses a perl-based make system which ends up
with very installation-specific and perl-version-specific target
paths, but I don't know if these paths are actually used in the final
product. Will I need to put Makefile.PL, etc., in the binary rpm
itself, and build the perl interface on the fly for every target
machine? Can I instead just plop some files into the proper place on
the target machine in a version-independent way?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> I'm now trying to package the perl (and next, python) interfaces. Can > someone with perl installation experience give me some hints on what > actually needs to be installed and how it has to happen? Me thinks the guy who's building the Debian packages should have some experience with these. IIRC that'd be Oliver Elphick (?). (just imagine, redhat and debian cooperating, hell must be freezing over ;) Maarten -- Maarten Boekhold, boekhold@tibco.com TIBCO Finance Technology Inc. The Atrium Strawinskylaan 3051 1077 ZX Amsterdam, The Netherlands tel: +31 20 3012158, fax: +31 20 3012358 http://www.tibco.com
Thomas Lockhart wrote:
>
> > For v6.5, I think I'm going to do the phased build (the "repeating"
> > option).
>
> OK, I think I've got a good start at a Postgres-6.5 rpm set. It will
> have the apps using shared libraries, rather than static links. It
> includes more interfaces than past rpms, including ODBC, and I've
> separated out the language-specific features into separate rpms (e.g.
> the tcl interfaces are in postgres-tcl-6.5-1.rpm).
>
> I'm now trying to package the perl (and next, python) interfaces. Can
> someone with perl installation experience give me some hints on what
> actually needs to be installed and how it has to happen?
>
> The Postgres source tree uses a perl-based make system which ends up
> with very installation-specific and perl-version-specific target
> paths, but I don't know if these paths are actually used in the final
> product. Will I need to put Makefile.PL, etc., in the binary rpm
> itself, and build the perl interface on the fly for every target
> machine? Can I instead just plop some files into the proper place on
> the target machine in a version-independent way?
The incantation
perl -MConfig -e 'print $Config{archlib},"\n"'
will give you the directory where things need to go.
The pm file goes directly in archlib. The sharedlib and the bootstrap
file go in <archlib>/auto/<extension-name>
<archlib>/Postgres.pm
<archlib>/auto/Postgres/Postgres.so
<archlib>/auto/Postgres/Postgres.bs
That would be a start.
---
Mark Hollomon
mhh@nortelnetworks.com
Maarten Boekhold wrote: > >> I'm now trying to package the perl (and next, python) interfaces. Can >> someone with perl
installationexperience give me some hints on what >> actually needs to be installed and how it has to happen? > >Me
thinksthe guy who's building the Debian packages should have some >experience with these. IIRC that'd be Oliver Elphick
(?).
The Perl package gave me the most trouble; the more so since I rarely
use Perl and only have the vaguest notion of what's going on in the pgperl
build!
Here are extracts from the Debian makefile:
HERE := $(shell pwd)
debtmp= $(HERE)/debian/tmp # pgperl package gets put in #
$(debtmp)/../libpgperl
src/config.cache: cd src &&\ echo /usr/include/ncurses /usr/include/readline | \ ./configure
--prefix=$(HERE)/debian/tmp/usr/lib/postgresql\ --with-template=$(TEMPLATE) \ --with-tcl \
--enable-locale \ --with-pgport=5432
perl-config: src/config.cache cd src/interfaces/perl5 && \ INSTALLDIRS=perl \
PREFIX=$(debtmp)/usr \ POSTGRES_HOME=$(debtmp)/usr/lib/postgresql \
INSTALLMAN1DIR=$(debtmp)/usr/man/man1\ INSTALLMAN3DIR=$(debtmp)/usr/man/man3 \
OVERRIDE=true \ perl Makefile.PL && \ touch perl-config
perl-build: build cp -a src/include $(debtmp)/usr/lib/postgresql/ cp src/interfaces/libpq/*.h
$(debtmp)/usr/lib/postgresql/include cd src/interfaces/perl5 && \ $(MAKE) PREFIX=$(debtmp)/usr \
POSTGRES_HOME=$(debtmp)/usr/lib/postgresql \ INSTALLDIRS=perl \
INSTALLMAN1DIR=$(debtmp)/usr/man/man1 \ INSTALLMAN3DIR=$(debtmp)/usr/man/man3 \
LDDLFLAGS="-shared -L$(debtmp)/usr/lib" \ LDFLAGS=-L../libpq \
LDLOADLIBS="-L../libpq-lpq -lc" rm -rf $(debtmp)/usr/lib/postgresql/include
binary-arch: build-test perl-build install-python # patch current arch into libpgperl's directory and file
lists sed 's/%ARCH%/$(ARCH)/g' <debian/libpgperl.dirs.in >debian/libpgperl.dirs sed 's/%ARCH%/$(ARCH)/g'
<debian/libpgperl.files.in>debian/libpgperl.files dh_installdirs -a # install files into the
debian/<package>trees ... cd src/interfaces/perl5 && \ $(MAKE) PREFIX=$(debtmp)/usr \
POSTGRES_HOME=$(debtmp)/usr/lib/postgresql \ INSTALLDIRS=perl \
INSTALLMAN1DIR=$(debtmp)/usr/man/man1\ INSTALLMAN3DIR=$(debtmp)/usr/man/man3 \
LDDLFLAGS="-shared -L$(debtmp)/usr/lib" \ LDFLAGS=-L../libpq \
pure_install ... rm -f debian/libpgperl/usr/lib/perl5/i386-linux/5.004/auto/Pg/.packlist rm -rf
$(debtmp)/usr/lib/perl5 rm -rf debian/libpgperl/usr/lib/perl5/i386
If you want the full works, download the Debian source package for
PostgreSQL - 6.4.2 will do (Debian's current unstable version, shortly
to be replaced by 6.5)
>(just imagine, redhat and debian cooperating, hell must be freezing >over ;)
Just comfortably warm, thanks!
-- Vote against SPAM: http://www.politik-digital.de/spam/ ========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key
ID32B8FAA1 ======================================== "The Spirit of the Lord is upon me, because he
hath anointed me to preach the gospel to the poor; he hath sent me to heal the brokenhearted, to preach
deliveranceto the captives, and recovering of sight to the blind, to set at liberty them that are
bruised..." Luke 4:18
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> The Postgres source tree uses a perl-based make system which ends up
> with very installation-specific and perl-version-specific target
> paths, but I don't know if these paths are actually used in the final
> product. Will I need to put Makefile.PL, etc., in the binary rpm
> itself, and build the perl interface on the fly for every target
> machine? Can I instead just plop some files into the proper place on
> the target machine in a version-independent way?
I believe you would be making unsafe assumptions about both the
installed version of Perl and the location of the Perl install tree
if you do not run through the regular Perl module install procedure
("perl Makefile.PL ; make ; make install"). There is also a permissions
issue, although if rpms are normally unpacked as root that might not
matter.
I'm not very familiar with the RPM installation culture --- perhaps you
can get away with packaging a Perl module that is dependent on the
assumption that a particular existing RPM of Perl has been installed.
But I'd suggest keeping it separate from the main Postgres RPM ...
regards, tom lane
Oliver Elphick wrote: > > Maarten Boekhold wrote: > > > >> I'm now trying to package the perl (and next, python) interfaces. Can > >> someone with perl installation experience give me some hints on what > >> actually needs to be installed and how it has to happen? > > > >Me thinks the guy who's building the Debian packages should have some > >experience with these. IIRC that'd be Oliver Elphick (?). > > The Perl package gave me the most trouble; the more so since I rarely > use Perl and only have the vaguest notion of what's going on in the pgperl > build! > I don't know the peculiarities of every distribution, but the following will work in any case: tar xvzf postgres-6.5.tar.gz cd $POSTGRES_HOME/src ./configure make install initdb --pgdata=/usr/local/pgsql/data --pglib=/usr/local/pgsql/lib postmaster -S -D /usr/local/pgsql/data createuser my_userid make sure, the dynamic linker can find libpq.so eg: export LD_LIBRARY_PATH=/usr/local/pgsql/lib cd interfaces/pgsql_perl5 perl Makefile.PL make test su make install Edmund -- Edmund Mergl mailto:E.Mergl@bawue.de http://www.bawue.de/~mergl
> cd interfaces/pgsql_perl5
> perl Makefile.PL
> make test
> su
> make install
The rpm format would prefer to build *all* files on a source machine,
and then move them from the rpm file into the appropriate places on
target machines. The problem is that, apparently, perl Makefile.PL
generates paths which are *very* specific to the version of perl on
the source machine, and which may not be compatible with versions of
perl on the target machines. Assuming that the code generated is a bit
more tolerant of version changes in perl, then I need to figure out
where the code would go on the target machines. One possibility is to
simply lift all of the perl5 source tree into the rpm, and actually do
the build on the target machine from scratch. afaik, this is *not* the
preferred style for rpms.
Mark Hoffman and Oliver Elphick (who also has helped with my python
questions) have given me some good clues; I'll keep asking questions
until I can get something which works...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> ... Assuming that the code generated is a bit
> more tolerant of version changes in perl,
I believe that's nearly as risky as hardwiring the install path.
For example, we already know that the existing perl5 interface
*source* code is broken for the latest Perl releases (5.005something),
nevermind trying to make the object code compatible. (I'm going
to try to figure out whether we can tweak the source to work under
either version ... it may take conditional compilation :-( ... if
anyone else is in a bigger hurry than me, be my guest ...)
> One possibility is to
> simply lift all of the perl5 source tree into the rpm, and actually do
> the build on the target machine from scratch. afaik, this is *not* the
> preferred style for rpms.
It may be swimming upstream in the RPM culture, but it should work
and work reliably. *Not* doing the expected configuration on the
target machine will be swimming upstream in the Perl culture, and
I'll wager that the undertow is a lot more dangerous in that case.
regards, tom lane
> It may be swimming upstream in the RPM culture, but it should work
> and work reliably. *Not* doing the expected configuration on the
> target machine will be swimming upstream in the Perl culture, and
> I'll wager that the undertow is a lot more dangerous in that case.
Yup. I'll probably end up trying to package all of the source code
into the binary rpms, with an install script. But I think my first cut
will try to force the generated files into the correct place. I've got
lots of other interfaces to handle, and want to get the rpms out as a
beta trial asap.
We'll see how long it takes someone to break the rpm :/
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Then <lockhart@alumni.caltech.edu> spoke up and said: > > > It may be swimming upstream in the RPM culture, but it should work > > and work reliably. *Not* doing the expected configuration on the > > target machine will be swimming upstream in the Perl culture, and > > I'll wager that the undertow is a lot more dangerous in that case. > > Yup. I'll probably end up trying to package all of the source code > into the binary rpms, with an install script. But I think my first cut > will try to force the generated files into the correct place. I've got > lots of other interfaces to handle, and want to get the rpms out as a > beta trial asap. Wouldn't it be better to create a CPAN package and distribute it from *there*? I realize that this method has the problem that package updates and PostgreSQL updates could become desynchronized, but I think this would address the issue adequately. -- ===================================================================== | JAVA must have been developed in the wilds of West Virginia. | | After all, why else would it support only single inheritance?? | ===================================================================== | Finger geek@cmu.edu for my public key. | =====================================================================
> Wouldn't it be better to create a CPAN package and distribute it from
> *there*? I realize that this method has the problem that package
> updates and PostgreSQL updates could become desynchronized, but I
> think this would address the issue adequately.
Well, the problem I'm trying to solve is rpm packaging, which is not
necessarily the same as solving the perl distribution issue.
However...
Would a CPAN package be more amenable to an rpm packaging? That is, if
we had a CPAN distribution (generated locally, of course), could I
plop that into an rpm and have a standard, easy procedure to follow
within the rpm to get the stuff extracted and installed onto a
machine?? I'm blissfully ignorant about CPAN and the packaging
conventions, but would like suggestions.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Wouldn't it be better to create a CPAN package and distribute it from
>> *there*?
> Would a CPAN package be more amenable to an rpm packaging? That is, if
> we had a CPAN distribution (generated locally, of course), could I
> plop that into an rpm and have a standard, easy procedure to follow
> within the rpm to get the stuff extracted and installed onto a
> machine?? I'm blissfully ignorant about CPAN and the packaging
> conventions, but would like suggestions.
I believe that what you find in the interfaces/perl5 subdirectory
*is* a CPAN package. Tarred and gzipped, that fileset could be
submitted to CPAN (or it could be if it was self-contained, rather than
dependent on libpq, that is). "perl Makefile.PL; make; make install"
is precisely what Perl users expect to have to do with a CPAN package.
I'm not sure if it's worth trying to come up with a self-contained
CPAN package or not --- we could probably make one, using libpq sources
and the necessary backend include files, but would it really be worth
much to anyone who didn't also have a Postgres server? Seems like you
need the full distribution anyway, in most situations.
regards, tom lane
On Tue, 29 Jun 1999, Thomas Lockhart wrote: > The rpm format would prefer to build *all* files on a source machine, > and then move them from the rpm file into the appropriate places on > target machines. The problem is that, apparently, > perl Makefile.PL > generates paths which are *very* specific to the version of perl on That should not be the case. It depends on how the Postgres package Makefile.PL is written, but in general it should go into a general use perl5 directory, such as /usr/lib/perl5/site_perl, which is anything but perl version dependant. If it generates paths that are perl version dependent then the Makefile.PL is busted. > One possibility is to > simply lift all of the perl5 source tree into the rpm, and actually do > the build on the target machine from scratch. afaik, this is *not* the > preferred style for rpms. No, that is definitely not th way to handle packages distributed by rpm. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~UNIX is user friendly. It's just selective about whoits friends are.
On Mon, 28 Jun 1999, Thomas Lockhart wrote: > machine? Can I instead just plop some files into the proper place on > the target machine in a version-independent way? On a Red Hat system you can use /usr/lib/perl5/site_perl, for example. That is not dependent on perl version. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~UNIX is user friendly. It's just selective about whoits friends are.
Cristian Gafton wrote: > > On Tue, 29 Jun 1999, Thomas Lockhart wrote: > > > The rpm format would prefer to build *all* files on a source machine, > > and then move them from the rpm file into the appropriate places on > > target machines. The problem is that, apparently, > > perl Makefile.PL > > generates paths which are *very* specific to the version of perl on > > That should not be the case. It depends on how the Postgres package > Makefile.PL is written, but in general it should go into a general use > perl5 directory, such as /usr/lib/perl5/site_perl, which is anything but > perl version dependant. If it generates paths that are perl version > dependent then the Makefile.PL is busted. > /usr/local/lib/perl5/site_perl/5.005/i686-linux/Pg.pm this is the standard path for all additionally installed modules. It depends on the perl version as well as on the system type. > > One possibility is to > > simply lift all of the perl5 source tree into the rpm, and actually do > > the build on the target machine from scratch. afaik, this is *not* the > > preferred style for rpms. > > No, that is definitely not th way to handle packages distributed by rpm. > > Cristian > -- > ---------------------------------------------------------------------- > Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > UNIX is user friendly. It's just selective about who its friends are. Edmund -- Edmund Mergl mailto:E.Mergl@bawue.de http://www.bawue.de/~mergl
Cristian Gafton wrote: > > On Mon, 28 Jun 1999, Thomas Lockhart wrote: > > > machine? Can I instead just plop some files into the proper place on > > the target machine in a version-independent way? > > On a Red Hat system you can use /usr/lib/perl5/site_perl, for example. > That is not dependent on perl version. > > Cristian > -- > ---------------------------------------------------------------------- > Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > UNIX is user friendly. It's just selective about who its friends are. if you install a perl module in the standard way (make install) on a RedHat system, you will end up with the modules installed in: /usr/lib/perl5/site_perl/5.005/i386-linux/ A standard Makfile.PL does not contain any information about the target directories. This is always handled by perl itself. Edmund -- Edmund Mergl mailto:E.Mergl@bawue.de http://www.bawue.de/~mergl
Cristian Gafton <gafton@redhat.com> writes:
> On Tue, 29 Jun 1999, Thomas Lockhart wrote:
>> The problem is that, apparently,
>> perl Makefile.PL
>> generates paths which are *very* specific to the version of perl on
> That should not be the case. It depends on how the Postgres package
> Makefile.PL is written, but in general it should go into a general use
> perl5 directory, such as /usr/lib/perl5/site_perl, which is anything but
> perl version dependant. If it generates paths that are perl version
> dependent then the Makefile.PL is busted.
Au contraire. That may be true for pure-Perl packages, but packages
that involve compiled code (as our perl5 interface surely does) go
into strongly version-dependent directories. On my box, for example,
the install procedure wants to put stuff into both
/opt/perl5/lib/site_perl/PA-RISC1.1/auto/Pg/ and
/opt/perl5/lib/PA-RISC1.1/5.00404/
which means it is dependent on (a) where the Perl install tree is
(/opt/perl5 is standard on SysV-derived systems, but not elsewhere),
(b) the hardware architecture (PA-RISC1.1 here), and (c) the Perl
subversion (5.004_04 here).
The dependence on hardware architecture is obviously essential, since
the compiled code could not work anywhere else. You can quibble about
whether code compiled against 5.004_04 Perl headers would work on a
wider range of Perl versions, but the fundamental bottom line is that
Perl expects addon modules to be transported in source form and
compiled against the local installation. Violating that assumption
is a recipe for trouble.
regards, tom lane
On Wed, 30 Jun 1999, Edmund Mergl wrote: > > Makefile.PL is written, but in general it should go into a general use > > perl5 directory, such as /usr/lib/perl5/site_perl, which is anything but > > perl version dependant. If it generates paths that are perl version > > dependent then the Makefile.PL is busted. > > > > > /usr/local/lib/perl5/site_perl/5.005/i686-linux/Pg.pm You can drop it directly into /usr/local/lib/perl5/site_perl > this is the standard path for all additionally installed modules. > It depends on the perl version as well as on the system type. Nope, this is the standard path for modules that are made to be dependent on perl version and architecture. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~UNIX is user friendly. It's just selective about whoits friends are.
Hi Cristian! Glad you surfaced ;)
> > machine? Can I instead just plop some files into the proper place on
> > the target machine in a version-independent way?
> On a Red Hat system you can use /usr/lib/perl5/site_perl, for example.
> That is not dependent on perl version.
I see that now. For some reason the postgres v6.4.2 spec file didn't
quite handle the new perl tree, but between these hints and looking at
the mod_perl package (the perl extensions for apache) I think I see
how to do things.
Thanks for the help! I'm pretty sure I'm close to having some more
capable rpms for v6.5 than we've had in the past, but it wasn't at all
trivial! It's uncovered several small problems in our make system
which prevented this from happening earlier.
I'll be posting these on the Postgres web site for folks to test;
would you like me to send you a copy directly to look at? Somehow we
should coordinate this so my postgresql-6.5-1 doesn't conflict with
one coming from a RedHat distribution...
Regards.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Cristian Gafton wrote: > > On Wed, 30 Jun 1999, Edmund Mergl wrote: > > > > Makefile.PL is written, but in general it should go into a general use > > > perl5 directory, such as /usr/lib/perl5/site_perl, which is anything but > > > perl version dependant. If it generates paths that are perl version > > > dependent then the Makefile.PL is busted. > > > > > > > > > /usr/local/lib/perl5/site_perl/5.005/i686-linux/Pg.pm > > You can drop it directly into /usr/local/lib/perl5/site_perl > certainly you can, but you shouldn't. On our site we are running several hundred UNIX workstations including 5 different architectures, all of them using one NFS mounted /usr/local/lib/perl5 even with different versions of perl. This works pretty well and relies on the installation scheme site_perl/arch/version. If you start dropping modules directly into site_perl you will break this installation scheme. > > this is the standard path for all additionally installed modules. > > It depends on the perl version as well as on the system type. > > Nope, this is the standard path for modules that are made to be dependent > on perl version and architecture. No, if you do not prepare the Makefile.PL you will get as default the installation scheme described above. You have to make the module explicitely independent of architecture and version, but this is not desirable. > > Cristian > -- > ---------------------------------------------------------------------- > Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > UNIX is user friendly. It's just selective about who its friends are. -- Edmund Mergl mailto:E.Mergl@bawue.de http://www.bawue.de/~mergl