Re: Perl library (was Building Postgres)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Postgres Hackers List <hackers(at)postgreSQL(dot)org>, Edmund Mergl <E(dot)Mergl(at)bawue(dot)de>, Cristian Gafton <gafton(at)redhat(dot)com>
Subject: Re: Perl library (was Building Postgres)
Date: 1999-06-28 17:26:52
Message-ID: 18086.930590812@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-06-28 18:30:53 Re: [HACKERS] regression bigtest needs very long time
Previous Message Jan Wieck 1999-06-28 17:02:06 Re: [HACKERS] Adding "eval" to pl?