Re: Perl library (was Building Postgres) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Perl library (was Building Postgres)
Date
Msg-id 18086.930590812@sss.pgh.pa.us
Whole thread Raw
In response to Perl library (was Building Postgres)  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] Adding "eval" to pl?
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] regression bigtest needs very long time