Robert Treat wrote:

>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.
>
>


I suspect you are missing the point completely.

It is in fact not like building perl at all. I just downloaded
php-4.3.11 and got this from configure --help:

--with-pgsql[=DIR] Include PostgreSQL support. DIR is the PostgreSQL
base install directory, defaults to
/usr/local/pgsql.

You will not find any such parameter for building perl.

Now it is true that you don't need this in for plphp. But if you want
php to have pg client support you need pg built first. And no sane
packager is going to build php twice.

I understand (correct me if I'm wrong) that php is moving to get rid of
this compile-time dependency - but it's not gone yet, to the best of my
knowledge.

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

* Robert Treat (xzilla@users.sourceforge.net) wrote:
> 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...

Just to point it out, Debian handles circular dependencies like these
without too much difficulty. It's really only an issue when first
building the various packages, and then you just build one without all
the support initially, build the other, then rebuild the first with the
support.

So, in general, no, I don't think this should be justification for it
being part of the main source tree and as a Debian maintainer would much
prefer it be seperate and able to be compiled outside of the core
Postgres tree..

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCd8TarzgMPqB3kigRArvtAJwM+QGt5D8JegbjT+D8CW chFJpuqACeIR3P
lGmiHO4+AVSU1CsUy83NmqA=
=ioX+
-----END PGP SIGNATURE-----

On Tue, 3 May 2005, Andrew Dunstan wrote:

>
>
> Robert Treat wrote:
>
>> 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.
>
>
> I suspect you are missing the point completely.
>
> It is in fact not like building perl at all. I just downloaded php-4.3.11 and
> got this from configure --help:
>
> --with-pgsql[=DIR] Include PostgreSQL support. DIR is the PostgreSQL
> base install directory, defaults to
> /usr/local/pgsql.
>
> You will not find any such parameter for building perl.
>
> Now it is true that you don't need this in for plphp. But if you want php to
> have pg client support you need pg built first. And no sane packager is going
> to build php twice.

Actually, if you look through FreeBSD ports, this is exactly what happens
.... when you build /usr/ports/devel/php4, it builds a "vanilla" php, no
modules ... if you want pgsql support, you go into
/usr/ports/databases/php4-pgsql, and build that (which has a dependency on
lang/php4) ...

So, for plphp, a "port" would just have to install /usr/ports/lang/php4 to
build, but would not necessarily build php4-pgsql ...

it is done this way to avoid packagers having to build a monolithich
"contains everything" php4 ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > 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.
>
> "Outside packagers"? What makes you think PG RPMs are built by outside
> packagers? The PGDG RPMs are certainly built by us, and Red Hat's PG
> RPMs are built by somebody named Tom Lane, and last I heard Oliver
> Elphick was handling the Debian packaging. We have more control over
> those things than you might think. What we don't have control over is
> what the PHP people choose to put in their tarball ... and that means
> there's a circularity problem if we try to merge plphp. I think you
> are blaming the messengers.

Oliver's not the only Debian person working on the PostgreSQL packages
for Debian. Oliver certainly does a great deal of excellent work on the
core PostgreSQL packages, I don't mean to claim otherwise, but Martin
Pitt helps out a great deal with those, and various other packages are
maintained by others (such as the php4-pgsql packages, which appear to
currently be maintained by Steve Langasek, the libdbd-pg-perl packages
which appear to be maintained by Raphael Hertzog, etc).

Not arguing with you, you're right, Oliver's certainly one of the
maintainers of the Debian core PostgreSQL packages, just not the only
one.

Thanks,

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCd8ZcrzgMPqB3kigRAsshAKCEKaTtwcaFMtbalcccl0 Dwm/0c/QCgjzlq
1KX9pzWMt28ZZtZCGG0GFwQ=
=e5s2
-----END PGP SIGNATURE-----

* Marc G. Fournier (scrappy@postgresql.org) wrote:
> On Tue, 3 May 2005, Joshua D. Drake wrote:
> >We could break out all of the pls at that point? Where if you downloaded
> >postgresql-opt you would get plPHP, plPerl etc...
>
> Optimally, you would get rid of -opt altogether, and leave it as the
> individual pl(s) ... the main purposes of the smaller tar balls is so that
> someone building a port (*BSDs) or a package (other OSs) would only need
> to download the component that applies to them, and someone installing
> from source, similar ...

I tend to like this approach. I think it'd also make it possible to
have seperate Debian packages for the different languages more easily,
which may be useful since they could more easily have different
maintainers too. It'd also mean that you wouldn't have to have
languages installed (or at least, on the system, perhaps not
createlang'd) if you didn't want them, etc, etc.

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCd8c4rzgMPqB3kigRAtC0AJwLqi3kq/nEJSmZW8lYm1tv5ir6EgCfcjpb
wLVnsQzIYlm1x9oj1Cw+0OM=
=RIrI
-----END PGP SIGNATURE-----

Marc G. Fournier wrote:

>> Now it is true that you don't need this in for plphp. But if you want
>> php to have pg client support you need pg built first. And no sane
>> packager is going to build php twice.
>
>
> Actually, if you look through FreeBSD ports, this is exactly what
> happens ... when you build /usr/ports/devel/php4, it builds a
> "vanilla" php, no modules ... if you want pgsql support, you go into
> /usr/ports/databases/php4-pgsql, and build that (which has a
> dependency on lang/php4) ...
>
> So, for plphp, a "port" would just have to install
> /usr/ports/lang/php4 to build, but would not necessarily build
> php4-pgsql ...
>
> it is done this way to avoid packagers having to build a monolithich
> "contains everything" php4 ...
>

How ugly. [remaining comments unprintable]

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

* Marc G. Fournier (scrappy@postgresql.org) wrote:
> On Tue, 3 May 2005, Andrew Dunstan wrote:
> >Now it is true that you don't need this in for plphp. But if you want php
> >to have pg client support you need pg built first. And no sane packager is
> >going to build php twice.
>
> Actually, if you look through FreeBSD ports, this is exactly what happens
> ... when you build /usr/ports/devel/php4, it builds a "vanilla" php, no
> modules ... if you want pgsql support, you go into
> /usr/ports/databases/php4-pgsql, and build that (which has a dependency on
> lang/php4) ...
>
> So, for plphp, a "port" would just have to install /usr/ports/lang/php4 to
> build, but would not necessarily build php4-pgsql ...
>
> it is done this way to avoid packagers having to build a monolithich
> "contains everything" php4 ...

Indeed, Debian does this for a number of packages too, and I think we
actually split out the PHP4 stuff into seperate 'source' packages in
some cases which ends up making it not actually have to be a circular
dependency (similar to Perl).

Thanks,

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCd8ghrzgMPqB3kigRAkQnAKCPOdsRon49ebvwwrAy45 Ib1S4knwCffU4s
fFGrifHCG2w9IVeAqPEX2cw=
=Riv6
-----END PGP SIGNATURE-----

Stephen Frost wrote:
> Just to point it out, Debian handles circular dependencies like these
> without too much difficulty. It's really only an issue when first
> building the various packages, and then you just build one without
> all the support initially, build the other, then rebuild the first
> with the support.

I don't really believe that. People frequently do automated builds of
the entire archive from scratch . There cannot be true circular build
dependencies. That's the reason why the circular Qt <-> unixODBC
dependency isn't resolved yet.

Of course, on Debian, this whole discussion is moot anyway because the
php-pgsql client module is built from an independent source package for
other historic reasons.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

On Tue, 3 May 2005, Andrew Dunstan wrote:

>
>
> Marc G. Fournier wrote:
>
>>> Now it is true that you don't need this in for plphp. But if you want php
>>> to have pg client support you need pg built first. And no sane packager is
>>> going to build php twice.
>>
>>
>> Actually, if you look through FreeBSD ports, this is exactly what happens
>> ... when you build /usr/ports/devel/php4, it builds a "vanilla" php, no
>> modules ... if you want pgsql support, you go into
>> /usr/ports/databases/php4-pgsql, and build that (which has a dependency on
>> lang/php4) ...
>>
>> So, for plphp, a "port" would just have to install /usr/ports/lang/php4 to
>> build, but would not necessarily build php4-pgsql ...
>>
>> it is done this way to avoid packagers having to build a monolithich
>> "contains everything" php4 ...
>>
>
> How ugly. [remaining comments unprintable]

That's a matter of opinion ... in our environment, it means that clients
can enable/disable PHP features on a per VM basis without having to build
a new PHP binary for each ... *shrug*

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

>
>
> That's a matter of opinion ... in our environment, it means that clients
> can enable/disable PHP features on a per VM basis without having to
> build a new PHP binary for each ... *shrug*

Gentoo also does this

>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664


--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedication Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)