Thread

  1. Re: [HACKERS] Perl library (was Building Postgres)

    Oliver Elphick <olly@lfix.co.uk> — 1999-06-28T16:20:54Z

    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!
    
    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 ID 32B8FAA1
                     ========================================
         "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  
          deliverance to the captives, and recovering of sight 
          to the blind, to set at liberty them that are  
          bruised..."         Luke 4:18 
    
    
    
  2. Re: [HACKERS] Perl library (was Building Postgres)

    Edmund Mergl <e.mergl@bawue.de> — 1999-06-28T19:21:33Z

    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
    
    
  3. Re: [HACKERS] Perl library (was Building Postgres)

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-06-29T01:36:11Z

    > 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
    
    
  4. Re: [HACKERS] Perl library (was Building Postgres)

    Cristian Gafton <gafton@redhat.com> — 1999-06-30T04:24:17Z

    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 who its friends are.
    
    
    
    
    
  5. Re: [HACKERS] Perl library (was Building Postgres)

    Edmund Mergl <e.mergl@bawue.de> — 1999-06-30T04:47:12Z

    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
    
    
  6. Re: [HACKERS] Perl library (was Building Postgres)

    Cristian Gafton <gafton@redhat.com> — 1999-06-30T05:13:18Z

    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 who its friends are.
    
    
    
    
    
  7. Re: [HACKERS] Perl library (was Building Postgres)

    Edmund Mergl <e.mergl@bawue.de> — 1999-06-30T17:39:30Z

    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