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
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 s
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 a
* 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, 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 ex
> -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] [HACKE
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
> What is being worked on right now is effectively reducing
> >> things down
> to:
>
> postgresql-server (including libpq) postgresql- add on here>
> >>>
> >>> So you mean to get an equivalent of
> >> postgresql-8.0.2.tar.bz2, I will
> >>> have to download 30+ tarballs?
> >>
> >
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-
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 exi
c: Marc G. Fournier; Dave Page; Robert Treat; Tom Lane; Josh
> >> Berkus; pgsql-hackers@postgresql.org
> >> Subject: Re: [pgsql-advocacy] [HACKERS] Increased company
> involvement
> >>
> >> What is being worked on right now is effectively reducing
> >>
> >> What is being worked on right now is effectively reducing
> things down
> >> to:
> >>
> >> postgresql-server (including libpq)
> >> postgresql-
> >
> > 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 w
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
] Increased company involvement
What is being worked on right now is effectively reducing
things down to:
postgresql-server (including libpq)
postgresql-
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 exist from day one
* 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 se
> > 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 post
* 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
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 Eisentrau
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
> > 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
> p
> -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] [HACKE
> -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 c
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" w
>> 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 c
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 sym
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 hav
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
> -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] Incre
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'r
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 en
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 hacke
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 st
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?
>
: [pgsql-advocacy] [HACKERS] Increased company involvement
>
> 'k, I think we're talking about two different things right
> now .. both
> jdbc and odbc *are* on the main ftp servers right now ... or, rather,
> should be if ppl uploaded their distributions to their project file
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 i
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
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
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
> t
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 much
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
"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 lik
On Thu, 5 May 2005, Tom Lane wrote:
Josh Berkus 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
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.
Ye
Josh Berkus 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 have a report
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 tha
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 s
On Thu, 5 May 2005, Tom Lane wrote:
Josh Berkus 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
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, w
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
Josh Berkus 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 really like such
"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-m
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 the
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
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
not,
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 differ
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 Fran
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
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
"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
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 is
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 req
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 https://helixc
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 PROTEC
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 wierd
Josh Berkus 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 license and possi
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 buil
"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 f
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
"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 pos
On Wed, 4 May 2005, Joshua D. Drake wrote:
Tom Lane wrote:
Bruce Momjian 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-c
Tom Lane wrote:
Bruce Momjian 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. That means
Bruce Momjian 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. That means its own con
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
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
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 S
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 ever
ubject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement
>
> and I believe there are still alot of places in
> Europe (or is/was
> it just GB?) that pay per byte for their bandwidth ...
Not pay-per-byte as such (in .uk), but many people do use cheap lines
that have monthly
On Tue, 3 May 2005, Joshua D. Drake wrote:
Marc G. Fournier wrote:
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the tarball
is too big ( or have we )
Because ppl are downloading the "split distributions" instead of the whole
tarball ... *ev
On Tue, 3 May 2005, Dave Cramer wrote:
So nobody has complained about the tarball being too big; yet we made it
harder to use just in case someone might complain ?
Made what harder to use? You don't like the split, download the full tar
ball ... both options are available to you ... myself, I f
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 (Mambo) should really have two
> servers, at least to
So nobody has complained about the tarball being too big; yet we made
it harder to use just in case someone might complain ?
--dc--
Marc G. Fournier wrote:
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the
tarball is too big ( or have we )
Marc G. Fournier wrote:
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the
tarball is too big ( or have we )
Because ppl are downloading the "split distributions" instead of the
whole tarball ... *every* PostgreSQL related port in FreeBSD use
On Tue, 3 May 2005, Dave Cramer wrote:
How come we have never seen anyone complain on the lists that the tarball is
too big ( or have we )
Because ppl are downloading the "split distributions" instead of the whole
tarball ... *every* PostgreSQL related port in FreeBSD uses the
split-dists (only
On Tuesday 03 May 2005 13:51, Tom Lane 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 ta
Marc G. Fournier wrote:
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 ad
Marc G. Fournier wrote:
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*
Different issue. You can do that on RH
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
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
> 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 su
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 e
* Marc G. Fournier ([EMAIL PROTECTED]) 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
> i
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
* Marc G. Fournier ([EMAIL PROTECTED]) 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 l
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 /u
* 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 sho
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 so
* 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 po
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 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 ta
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 C
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 t
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
> >
1 - 100 of 185 matches
Mail list logo
