-Original Message-
From: Magnus Hagander [mailto:[EMAIL PROTECTED]
Sent: 05 May 2005 22:58
To: Marc G. Fournier; Dave Page
Cc: Robert Treat; Tom Lane; Josh Berkus; pgsql-hackers@postgresql.org
Subject: SV: [pgsql-advocacy] [HACKERS] Increased company involvement
-Original Message-
From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
Sent: 06 May 2005 01:15
To: Magnus Hagander
Cc: Marc G. Fournier; Dave Page; Robert Treat; Tom Lane; Josh
Berkus; pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Increased company
Actually, if the number of split files (whatever their names)
increase even further, may I suggest they are moved into a
subdir of
their own, keeping just the main distribution and the
README about the
splits in the main dir?
the main distribution will just be
On 5/6/05, Magnus Hagander [EMAIL PROTECTED] wrote:
Actually, if the number of split files (whatever their names)
postgresql-WTKS.tar.gz (with the kitchen sink) file
that contained
everything for those that really wanted to download it all ...
That would be
Am Donnerstag, 5. Mai 2005 23:47 schrieb Marc G. Fournier:
have against is that the names could get very long:
postgresql-fuzzystrmatch-8.0.2.tar.gz
the postgresql part just seems redundant ...
Not once you have downloaded it and don't remember where you got it from.
--
Peter Eisentraut
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Remind me again how this is actually *better*, and not just making life
a whole lot worse for me? And more specifically, for a new user that
doesn't know which files to download already, and will just grab the
default file.
Or the new user will go
Remind me again how this is actually *better*, and not just making
life a whole lot worse for me? And more specifically, for a
new user
that doesn't know which files to download already, and will
just grab
the default file.
Or the new user will go 'apt-get install postgresql' and
* Adrian Maier ([EMAIL PROTECTED]) wrote:
Once this 'wtks' will be available, I bet that most people who are
aware of its existance will prefer to download it because it would
be much more convenient.The name of the package will need
to be carefully chosen, though. wtks does not seem to
On Fri, 6 May 2005, Dave Page wrote:
-Original Message-
From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
Sent: 06 May 2005 01:15
To: Magnus Hagander
Cc: Marc G. Fournier; Dave Page; Robert Treat; Tom Lane; Josh
Berkus; pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS
On Fri, 6 May 2005, Peter Eisentraut wrote:
Am Donnerstag, 5. Mai 2005 23:47 schrieb Marc G. Fournier:
have against is that the names could get very long:
postgresql-fuzzystrmatch-8.0.2.tar.gz
the postgresql part just seems redundant ...
Not once you have downloaded it and don't remember where you
What is being worked on right now is effectively reducing
things down
to:
postgresql-server (including libpq)
postgresql-insert add on here
So you mean to get an equivalent of
postgresql-8.0.2.tar.bz2, I will
have to download 30+ tarballs?
Or the WTKS one ... which will
: [pgsql-advocacy] [HACKERS] Increased company
involvement
What is being worked on right now is effectively reducing
things down to:
postgresql-server (including libpq)
postgresql-insert add on here
So you mean to get an equivalent of postgresql-8.0.2.tar.bz2, I will
have to download 30
On Fri, 6 May 2005, Magnus Hagander wrote:
What is being worked on right now is effectively reducing
things down
to:
postgresql-server (including libpq)
postgresql-insert add on here
So you mean to get an equivalent of
postgresql-8.0.2.tar.bz2, I will
have to download 30+ tarballs?
Or the WTKS one
What is being worked on right now is effectively reducing
things down
to:
postgresql-server (including libpq) postgresql-insert
add on here
So you mean to get an equivalent of
postgresql-8.0.2.tar.bz2, I will
have to download 30+ tarballs?
Or the WTKS one ... which will
On Fri, 6 May 2005, Dave Page wrote:
- Who/how will the release processes for all these seperate projects be
coordinated?
Who does now? As far as I know, PLs or contrib files *aren't* tested by
the regression tests, so, at best, they are getting 'spotty testing' right
now when we release ... we
-Original Message-
From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
Sent: 06 May 2005 16:04
To: Dave Page
Cc: Marc G. Fournier; Magnus Hagander; Robert Treat; Tom
Lane; Josh Berkus; pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Increased company
On Fri, 6 May 2005, Magnus Hagander wrote:
For PLs, usually I do. Then I activate them as they are needed. For
contribs, no, I usually stick tsearch2 in there, but not many other
contribs.
See, me, I download/install a PL as required ... so being able to download
a nice tiny file that uses my
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
If you are on debian or a derivative, of course. I assume we are not
planning to abandon the users who build from source.
Not abandon them, no. That's where Marc's stuff comes into play really,
and the WTKS stuff.
(won't using apt-get get you a
On Fri, 6 May 2005, Stephen Frost wrote:
Honestly, I think WTKS will work for you, though you may end up
downloading more than you want and you'll have to ignore build failures
for those PLs you don't have the interpreters for.
Actually, that shouldn't be an issue ... the WTKS tar ball would have
On Fri, 6 May 2005, Dave Page wrote:
Yes, but isn't the point of the so-called WTKS to pull in other projects
like PL/R, libpqxx and a range of other external projects from places
like Gborg? We have precisely zero control over their quality.
Course we have control over it ... if it isn't up to
Marc G. Fournier wrote:
As far as I know, PLs or contrib files *aren't* tested by the
regression tests, so, at best, they are getting 'spotty testing' right
now when we release ... we know they build, that's it. And that won't
change before/after ... Andrew is looking to add PL testing to the
Josh Berkus wrote:
Not decided, but it's surely on the radar screen for this discussion.
Joe Conway's PL/R is in the back of my mind as well --- it likely has
a smaller userbase than the first two, but from a maintenance standpoint
it probably belongs on the same level.
Yeah, except PL/R has
pl-j and pl/java are working together to create a shared interface so
that
they can co-exist. This is the part that we wish to have added to the
main source
tree. It will just be the C portion of the code that does rely on the
backend.
Dave
Tom Lane wrote:
"Joshua D. Drake" [EMAIL
On 5/4/05, Russell Smith [EMAIL PROTECTED] wrote:
On Wed, 4 May 2005 04:40 am, Tom Copeland wrote:
On Tue, 2005-05-03 at 14:26 -0400, Mitch Pirtle wrote:
Of course, Mitch is running the second largest GForge site on the planet
(as far as I know) second only to
Joe Conway [EMAIL PROTECTED] writes:
I've considered relicensing PL/R with a BSD license, but I haven't been
able to decide whether I really can do that given libR's GPL status, and
I'm afraid it might tick off the R core developers if I do.
The direction I see this going in wouldn't require
On Thu, 5 May 2005, Dave Cramer wrote:
pl-j and pl/java are working together to create a shared interface so
that they can co-exist. This is the part that we wish to have added to
the main source tree. It will just be the C portion of the code that
does rely on the backend.
Note that what Tom
Marc G. Fournier [EMAIL PROTECTED] writes:
Note that what Tom is proposing is actually yanking *all* PLs from the
core source tree, but having them all within the core CVS ... I believe
his motivation is that he only has one CVSROOT to set to get at all the
files, but that they are seperate
What we are proposing is just including the C code which will have no
external
dependancies.
We understand that building the java pl's requires many tools which are
not normally
available to people building the source.
Dave
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Note
On Thu, 5 May 2005, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Note that what Tom is proposing is actually yanking *all* PLs from the
core source tree, but having them all within the core CVS ... I believe
his motivation is that he only has one CVSROOT to set to get at all the
Joe,
I've considered relicensing PL/R with a BSD license, but I haven't been
able to decide whether I really can do that given libR's GPL status, and
I'm afraid it might tick off the R core developers if I do.
Seems like you could ask them.
--
Josh Berkus
Aglio Database Solutions
San
Tom Lane wrote:
I want them all in the same CVS basically to avoid any version skew
issues. They should always have the same branches and the same tags
as the core, for instance; and it seems hard to keep separate
repositories in sync that closely.
Can you have the same tags across different
On Thu, 5 May 2005, Peter Eisentraut wrote:
Can you have the same tags across different modules in the same CVS
server? If so, that would work.
I believe that I can made a 'meta module' that, if I checked it out, would
include all sub-modules, and that I can tag/branch appropriately ... if
Tom,
But packaging them as separately buildable tarballs that depend only
on the installed core fileset (headers + pgxs) seems a fine idea.
I really can't see doing this without a better (i.e. CPAN / emerge / ports -
like ) build system.Mind you, I'd really like such a build system, but
Peter Eisentraut wrote:
Tom Lane wrote:
I want them all in the same CVS basically to avoid any version skew
issues. They should always have the same branches and the same tags
as the core, for instance; and it seems hard to keep separate
repositories in sync that closely.
Can you have
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 5 May 2005, Peter Eisentraut wrote:
Can you have the same tags across different modules in the same CVS
server? If so, that would work.
I believe that I can made a 'meta module' that, if I checked it out, would
include all sub-modules,
Josh Berkus josh@agliodbs.com writes:
But packaging them as separately buildable tarballs that depend only
on the installed core fileset (headers + pgxs) seems a fine idea.
I really can't see doing this without a better (i.e. CPAN / emerge / ports -
like ) build system.Mind you, I'd
Josh Berkus wrote:
Seems like you could ask them.
Done that. They give about the same reaction as we do when someone
suggests Postgres should be GPL'd
Joe
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
On Thu, 5 May 2005, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 5 May 2005, Peter Eisentraut wrote:
Can you have the same tags across different modules in the same CVS
server? If so, that would work.
I believe that I can made a 'meta module' that, if I checked it out,
On Thu, 5 May 2005, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
But packaging them as separately buildable tarballs that depend only
on the installed core fileset (headers + pgxs) seems a fine idea.
I really can't see doing this without a better (i.e. CPAN / emerge / ports -
like )
On Thu, 5 May 2005, Andrew Dunstan wrote:
Peter Eisentraut wrote:
Tom Lane wrote:
I want them all in the same CVS basically to avoid any version skew
issues. They should always have the same branches and the same tags
as the core, for instance; and it seems hard to keep separate
repositories in
Tom,
Uh, that's not exactly what is being proposed. It would be a separate
tarball that you could untar wherever you felt like, because it would
not depend on the core source tree at all --- only on the files
installed by a previous build of the core.
Still sounds good. Do you think that
Josh Berkus josh@agliodbs.com writes:
Still sounds good. Do you think that this system could be extended to other
add-ons in the future which are currently more complex builds? And allow us
to out some of the wierder things in /contrib?
The system already exists --- it's pgxs. We already
Tom,
I have no problem with pushing out any part of contrib that doesn't seem
tightly tied to the core server. I'm not entirely sure where to draw
the line, but for instance I'd probably want to keep dblink where it is,
since functions-returning-records are still in considerable flux.
Yes, I
On Thu, 5 May 2005, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
Still sounds good. Do you think that this system could be extended to other
add-ons in the future which are currently more complex builds? And allow us
to out some of the wierder things in /contrib?
The system already
Marc G. Fournier [EMAIL PROTECTED] writes:
On Thu, 5 May 2005, Tom Lane wrote:
I have no problem with pushing out any part of contrib that doesn't seem
tightly tied to the core server.
Can I suggest that we focus on PLs first and foremost, since that will
allow us to get stuff like pl/PHP,
Marc G. Fournier wrote:
Do we want to consider adding in a mirror of the JDBC/ODBC stuff in
the same way? Based on the direction we are taking, I'm all for it ..
the idea being that when beta starts, the JDBC folk (or ODBC, or ?)
would submit a mega patch to be applied to the tree and tag'd
On Thu, 5 May 2005, Tom Lane wrote:
Can I suggest that we focus on PLs first and foremost, since that will
allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place,
and then ramp up other stuff as time permits?
Agreed.
'k, if there are no disagreements ... I can't see there being
On Thu, May 05, 2005 at 03:25:45PM -0300, Marc G. Fournier wrote:
'k, if there are no disagreements ... I can't see there being much we need
to do to get started ... I don't need a fully working and buildable
package to do the initial module load in CVS, so I think its pretty safe
to say
Marc G. Fournier wrote:
This is not to say that we might not want to adjust our
distribution setup so that it's easier for people to find 'em ---
that is, we could put JDBC/ODBC tarballs on the main ftp servers.
But I don't see the need for any coupling inside CVS.
Hrmmm, that would be
On Thu, 5 May 2005, Alvaro Herrera wrote:
On Thu, May 05, 2005 at 03:25:45PM -0300, Marc G. Fournier wrote:
'k, if there are no disagreements ... I can't see there being much we need
to do to get started ... I don't need a fully working and buildable
package to do the initial module load in CVS,
On Thu, 5 May 2005, Peter Eisentraut wrote:
Marc G. Fournier wrote:
This is not to say that we might not want to adjust our
distribution setup so that it's easier for people to find 'em ---
that is, we could put JDBC/ODBC tarballs on the main ftp servers.
But I don't see the need for any coupling
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc
G. Fournier
Sent: 05 May 2005 20:21
To: Peter Eisentraut
Cc: Marc G. Fournier; Tom Lane; Josh Berkus;
pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Increased company
On Thursday 05 May 2005 14:25, Marc G. Fournier wrote:
On Thu, 5 May 2005, Tom Lane wrote:
Can I suggest that we focus on PLs first and foremost, since that will
allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place,
and then ramp up other stuff as time permits?
Agreed.
On Thu, 5 May 2005, Robert Treat wrote:
On Thursday 05 May 2005 14:25, Marc G. Fournier wrote:
On Thu, 5 May 2005, Tom Lane wrote:
Can I suggest that we focus on PLs first and foremost, since that will
allow us to get stuff like pl/PHP, pl/Java, pl/J(?), and pl/R in place,
and then ramp up other
Marc,
all released at the same time, and tag'd the same way, and available under
the same ftp directory ...
Hmmm. As licensing permits, I think we should also offer a kitchen sink
download for those who want it. Which a lot of people will.
I believe that GreenPlum has a serious CVS hacker
On Thu, 5 May 2005, Josh Berkus wrote:
Marc,
all released at the same time, and tag'd the same way, and available under
the same ftp directory ...
Hmmm. As licensing permits, I think we should also offer a kitchen sink
download for those who want it. Which a lot of people will.
'k, how do you
Marc,
I've seen some projects where configure *calls* configure in sub
directories ... but that becomes a build issue if someone wants to try and
tackle that?
Yes, that's what I was proposing that I pitch to the folks at Greenplum that
they help with. Might be hard, though, because they're
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc
G. Fournier
Sent: 05 May 2005 21:08
To: Robert Treat
Cc: Tom Lane; Josh Berkus; pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On Thu, 5 May 2005, Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc
G. Fournier
Sent: 05 May 2005 21:08
To: Robert Treat
Cc: Tom Lane; Josh Berkus; pgsql-hackers@postgresql.org
Subject: Re: [pgsql-advocacy] [HACKERS] Increased
dbsize.tar.gz
btree_gist.tar.gz
etc
The end result wouldn't have enough in the *core* module to warrant a
split-dist anymore, since all of what would be left would be what is
required for a build ...
I know some of this is symantic but I think it would be better to
On Thu, 5 May 2005, Joshua D. Drake wrote:
dbsize.tar.gz
btree_gist.tar.gz
etc
The end result wouldn't have enough in the *core* module to warrant a
split-dist anymore, since all of what would be left would be what is
required for a build ...
I know some of this is
Commenting more broadly on the whole thread, I think that
more tarballs
is a bad thing. I already get emails (both to webmaster and
privately)
from people not understanding what to download - more files
will only
make that worse.
Going this route will eliminate alot of the confusion,
On Thu, 5 May 2005, Magnus Hagander wrote:
Actually, if the number of split files (whatever their names) increase
even further, may I suggest they are moved into a subdir of their own,
keeping just the main distribution and the README about the splits in
the main dir?
the main distribution will
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marc
G. Fournier
Sent: 03 May 2005 19:09
To: Joshua D. Drake
Cc: Marc G. Fournier; Tom Lane; Peter Eisentraut; Bruce
Momjian; PostgreSQL-development
Subject: Re: [pgsql-advocacy] [HACKERS
On Wed, 4 May 2005 04:40 am, Tom Copeland wrote:
On Tue, 2005-05-03 at 14:26 -0400, Mitch Pirtle wrote:
If you guys are planning on running Gforge, then you better make 'box'
plural.
I'm running MamboForge.net, and the poor thing is getting beat into
the cold hard earth every day. We
On Mon, 2 May 2005, Alvaro Herrera wrote:
The 2PC patch by Heikki Linnakangas (sp?) is also waiting and so far I
haven't seen any indication that it may be merged.
Actually, its one of the features we have planned to have merged for 8.1
... :)
Marc G. Fournier Hub.Org Networking
On Monday 02 May 2005 15:12, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Mon, 2 May 2005, Bruce Momjian wrote:
Marc G. Fournier wrote:
Then what is the point of having it in CVS? Other then to make are tar
ball bigger?
So it can be maintained with other PL languages
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
Bruce Momjian pgman@candle.pha.pa.us writes:
My idea is that the second stage would just have them go to src/pl/plphp
and type 'gmake install'.
Absolutely not. It has to work as an independent package, not as
something that expects to build inside an already-configured Postgres
source tree.
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
My idea is that the second stage would just have them go to src/pl/plphp
and type 'gmake install'.
Absolutely not. It has to work as an independent package, not as
something that expects to build inside an already-configured Postgres
On Wed, 4 May 2005, Joshua D. Drake wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
My idea is that the second stage would just have them go to src/pl/plphp
and type 'gmake install'.
Absolutely not. It has to work as an independent package, not as
something that expects to
Marc G. Fournier [EMAIL PROTECTED] writes:
On Wed, 4 May 2005, Joshua D. Drake wrote:
So where are we going?
plphp.tar.gz being seperately buildable from the core distribution,
without the core distribution source files ...
That is, plphp should build against an installed set of postgres
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
On Wed, 4 May 2005, Joshua D. Drake wrote:
So where are we going?
plphp.tar.gz being seperately buildable from the core distribution,
without the core distribution source files ...
That is, plphp should build against an installed set of
Joshua D. Drake [EMAIL PROTECTED] writes:
Kind of offtopic but at that point should we also include plJava?
Not decided, but it's surely on the radar screen for this discussion.
Joe Conway's PL/R is in the back of my mind as well --- it likely has
a smaller userbase than the first two, but from
Tom,
Not decided, but it's surely on the radar screen for this discussion.
Joe Conway's PL/R is in the back of my mind as well --- it likely has
a smaller userbase than the first two, but from a maintenance standpoint
it probably belongs on the same level.
Yeah, except PL/R has wierd build
Josh Berkus josh@agliodbs.com writes:
Joe Conway's PL/R is in the back of my mind as well
Yeah, except PL/R has wierd build requirements (FORTRAN) and different
licensing (R is GPL). :-(
[ shrug... ] All of the PLs except plpgsql require an outside language
interpreter that has its own
Another example is the recent patch to check if there are orphaned file
system files. That was submitted, Tom had questions, I posted why I
thought it was valid, and the patch is going in today. Anyone has the
ability to argue their point and try to sway the community, and any
member has
Bruce Momjian wrote:
(Funny, no one says I have too much power. I will have to look into how
to get some someday.) :-)
I think you have power, too. :-) You have commited many patches that some
other commiters didn't like that much and would rather not have applied
themselves. All with some
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
* Peter Eisentraut ([EMAIL PROTECTED]) 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
Peter Eisentraut [EMAIL PROTECTED] 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
On Tue, 3 May 2005, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] 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
Stephen Frost wrote:
* Peter Eisentraut ([EMAIL PROTECTED]) 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
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
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
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...
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
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.
On Tue, 3 May 2005, Joshua D. Drake wrote:
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
My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that can
be accomplished, then my main objection to adding things to the core CVS
are eliminated ...
I guess I don't see the problem of the PostgreSQL distribution
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.
Robert Treat [EMAIL PROTECTED] 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
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
On Tue, 3 May 2005, Joshua D. Drake wrote:
My primary desire is to avoid having to download several Meg of tar ball(s)
in order to add a module to an existing server ... if that can be
accomplished, then my main objection to adding things to the core CVS are
eliminated ...
I guess I don't see
On Tue, 3 May 2005, Marc G. Fournier wrote:
On Tue, 3 May 2005, Joshua D. Drake wrote:
My primary desire is to avoid having to download several Meg of tar
ball(s) in order to add a module to an existing server ... if that can be
accomplished, then my main objection to adding things to the core
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
Mitch Pirtle wrote:
On 4/30/05, Jim C. Nasby [EMAIL PROTECTED] wrote:
If money's not an issue anymore, can we get a bigger box to host
pgfoundry on then? :)
If you guys are planning on running Gforge, then you better make 'box' plural.
Well we already run it :) For pgFoundry and you are correct
* Robert Treat ([EMAIL PROTECTED]) 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
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
* Tom Lane ([EMAIL PROTECTED]) wrote:
Robert Treat [EMAIL PROTECTED] 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
1 - 100 of 172 matches
Mail list logo
