Re: [pgsql-advocacy] Increased company involvement - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [pgsql-advocacy] Increased company involvement
Date
Msg-id 20050503133819.GD30011@ns.snowman.net
Whole thread Raw
In response to Re: [pgsql-advocacy] Increased company involvement  (Peter Eisentraut)
Responses Re: [pgsql-advocacy] Increased company involvement  ("Joshua D. Drake")
List pgsql-hackers
* Peter Eisentraut () wrote:
> Am Montag, 2. Mai 2005 20:14 schrieb Bruce Momjian:
> > I posted this compromise and no one replied so I thought everyone was OK
> > with it.  It gets it into CVS, but has a separate compile stage to deal
> > with the recursive dependency problem.
>
> How will a "separate compile stage" work for actually building, say, RPM or
> Debian packages?  The only way I can see is wrapping up the PostgreSQL
> distribution tarball a second time as a "plphp" source package and build from
> there, which seems quite weird.

More than a little ugly, no thanks, please don't...

It should really be made to be buildable outside of the PostgreSQL
source tree, depending only upon the server API (which is provided in a
seperate Debian package which plphp could build-depend on).  This is
exactly how Slony will be packaged too..  From what I've gathered it
sounds like the only issue with this is that it may not get updated when
the server API changes?  Are there other issues?  Is there something it
needs that isn't or can't be provided by a seperate server API package?

(For those curious- my current plans are that slony will actually
generate a couple differnet binary debs, slon, slonik and
libpostgresql-slon or so.  libpostgresql-slon will have the .so which is
installed in the postgresql libdir, slon and slonik have their
associated programs and supporting things (.sql scripts, etc)).
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: des@des.no (Dag-Erling Smørgrav)
Date:
Subject: Regression tests
Next
From: "Merlin Moncure"
Date:
Subject: Re: pg_locks needs a facelift