From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | Brian E Gallew <geek+(at)cmu(dot)edu>, Edmund Mergl <E(dot)Mergl(at)bawue(dot)de>, Postgres Hackers List <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Perl library (was Building Postgres) |
Date: | 1999-06-29 21:32:05 |
Message-ID: | 20693.930691925@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:
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jackson, DeJuan | 1999-06-29 21:32:26 | RE: [HACKERS] changing major/minor on libpq for releases ... |
Previous Message | Tom Lane | 1999-06-29 21:21:07 | Re: [HACKERS] changing major/minor on libpq for releases ... |