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

From Robert Treat
Subject Re: [pgsql-advocacy] Increased company involvement
Date
Msg-id 200505031400.42301.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: [pgsql-advocacy] Increased company involvement  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [pgsql-advocacy] Increased company involvement
Re: [pgsql-advocacy] Increased company involvement
List pgsql-hackers
On Tuesday 03 May 2005 13:46, Andrew Dunstan wrote:
> Robert Treat wrote:
> >Is telling the rpm maintainers to go fix their rpm's an option?  As has
> >been hashed out before, the only thing that makes plphp different from
> >other pl's is that some of the current packagers are taking shortcuts
> >with the packaging scripts which introduces dependency issues. IMHO what
> >is included in the postgresql cvs and what is included in the main
> >tarball for postgresql should not be dictated by outside packagers.
>
> That wasn't my understanding of the previous discussion. Does not php
> require pg client support configured in at build time?
>

If your compiling it from source, it works similarly to perl... you only need 
pg when compiling pg support into php, but you dont need tthis in for plphp. 

The problem stems from things like the php rpm spec, which has a module 
dependency on postgresql.  This would create a circular dependency if we were 
to put a dependency into the pg rpm spec for plphp.  

I think the solution to this is to create a seperate rpm spec for php-pgsql 
support, which would fall in line with how the php rpm packages are 
distributed, but I'm not an expert in rpm specs...

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement
Next
From: "Dave Held"
Date:
Subject: Re: Feature freeze date for 8.1