Stephen Frost wrote:
> * Peter Eisentraut (peter_e@gmx.net) 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...
Not really that ugly. It is just an extra compile step. Besides
you don't have to package it just because it is in the Tarball.
Sincerely,
Joshua D. Drake
Command Prompt, Inc.
>
> 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