On Tue, Apr 05, 2005 at 06:06:09PM +1000, Russell Smith wrote: > The issue also includes the fact that you can't install libpq without having postgresql > installed. If you could do that, the circular dependency wouldn't exist. > > Some systems build postgresql into php, given that is the case, what Tom says is correct. > First you would have to force postgresql to be installed without pl/php. Then install php > with postgresql support, then install pl/php. > > OR > > Install php without postgresql support > Install postgresql with pl/php > Rebuild php with postgresql support (Unless you only want it available in the db) Take for example Debian, it autobuilds any source package on 11 architectures or so. The rule is, install dependancies, build source. It has to be reproducable. You can't build twice and get different results. Yes, if you're building it yourself you can do all sorts of trick, but autobuilders can't. Circular dependancies are a no-no. > I may be a bad man for suggesting it... But is it possible to ship libpq as a seperate > tarball that you can compile without postgresql server? I guess that seperate tarball would have to include pg_dump, pg_ctl and any of the other included programs that depend on libpq. Seperating server and client portions is an interesting idea. Ofcourse, the regression tests would become a third package and then you could spend time making them all match. I suppose the choice comes down to either PHP splitting the DB access (like other languages) or PostgreSQL splitting out pl/PHP. -- Martijn van Oosterhout <kleptog@xxxxxxxxx> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment:
pgpW7kj8lmC6l.pgp
Description: PGP signature
