SEO

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.

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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

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

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

iD8DBQFCd37KrzgMPqB3kigRAiudAKCFJtdankpC/HlQW3pOegqJzl3SRgCeIMzv
/N9OhGchawnlwTGw9kSfc7c=
=vNF0
-----END PGP SIGNATURE-----

Peter Eisentraut <peter_e@gmx.net> writes:
> 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.

I think the idea is that plphp would be in our CVS, but would not be
shipped as part of the main tarball, rather as its own separate tarball.

regards, tom lane

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

On Tue, 3 May 2005, Tom Lane wrote:

> Peter Eisentraut <peter_e@gmx.net> writes:
>> 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.
>
> I think the idea is that plphp would be in our CVS, but would not be
> shipped as part of the main tarball, rather as its own separate tarball.

That is what I'm hoping for ... if it can be shipped as a seperate
tarball, my arguments *against* including it become moot, since packagers
(and ports) can have a nice small, quick to download package instead of
having to re-download a >11MB file each time ...

I don't mind if its *also* ship'd in the main distribution as well, I just
want that 'quick to download since I already have the libraries/headers
installed' package ...

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

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


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

Joshua D. Drake wrote:
> 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.

Since you keep raising that point: Not packaging something is not a
valid solution to something being hard to package.

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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Marc G. Fournier wrote:
> On Tue, 3 May 2005, Tom Lane wrote:
>> I think the idea is that plphp would be in our CVS, but would not be
>> shipped as part of the main tarball, rather as its own separate tarball.
>
>
> That is what I'm hoping for ... if it can be shipped as a seperate
> tarball, my arguments *against* including it become moot, since
> packagers (and ports) can have a nice small, quick to download package
> instead of having to re-download a >11MB file each time ...
>
> I don't mind if its *also* ship'd in the main distribution as well, I
> just want that 'quick to download since I already have the
> libraries/headers installed' package ...
>
Any other PL's not currently in your CVS that you might consider to
bring in while you're at it?

Regards,
Thomas Hallgren


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

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.

Well like many rpms it will have an external dependency. You must have
perl installed to install plPerl. The main problem here is that you
would need a base install of php at a minimum.

The PHP installed would not need to support PostgreSQL at the time. In
fact now that I think about it depending on how you did it, this doesn't
effect PostgreSQl as much as it effects PHP.

You could compile and install plPHP+PostgreSQL as long as PHP was
installed regardless of the extensions that PHP supported at the time.
So you wouldn't need to compile PostgreSQL twice but you may need to
compile PHP twice. Once for plPHP and then once if you wanted PostgreSQL
support.

Sincerely,

Joshua D. Drake
Command Prompt, Inc.



>


--
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 6: Have you searched our list archives?

http://archives.postgresql.org

>
> I don't mind if its *also* ship'd in the main distribution as well, I
> just want that 'quick to download since I already have the
> libraries/headers installed' package ...

We could break out all of the pls at that point? Where if you downloaded
postgresql-opt you would get plPHP, plPerl etc...

Sincerely,

Joshua D. Drake



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


--
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 6: Have you searched our list archives?

http://archives.postgresql.org

On Tue, 2005-05-03 at 12:40, Peter Eisentraut wrote:
> Joshua D. Drake wrote:
> > 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.
>
> Since you keep raising that point: Not packaging something is not a
> valid solution to something being hard to package.
>

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.


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


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org