Darren Duncan dar...@darrenduncan.net writes:
Would now be a good time to start deprecating the contrib/ directory as a
way to distribute Pg add-ons, with favor given to PGXN and the like instead?
The first important fact is that contrib/ code is maintained by the
PostgreSQL-core product team,
On 05/18/2011 10:30 AM, Dimitri Fontaine wrote:
Darren Duncan dar...@darrenduncan.net writes:
Would now be a good time to start deprecating the contrib/ directory as a
way to distribute Pg add-ons, with favor given to PGXN and the like instead?
The first important fact is that contrib/ code
On May 18, 2011, at 10:30 AM, Dimitri Fontaine wrote:
The other problem is that the facility we need to provide the most is
binary distributions (think apt-get). Lots of site won't ever compile
stuff on their production servers. So while PGXN is a good tool, it's
not a universal answer.
On Wed, May 18, 2011 at 12:15 PM, David E. Wheeler da...@kineticode.com wrote:
On May 18, 2011, at 10:30 AM, Dimitri Fontaine wrote:
The other problem is that the facility we need to provide the most is
binary distributions (think apt-get). Lots of site won't ever compile
stuff on their
On May 18, 2011, at 12:24 PM, Christopher Browne wrote:
It'll be time to drop the contrib material from the core when that
shift leads to a 1 line configuration change somewhere that leads to
packages for Debian/Fedora/Ports drawing their code from the new spot.
I'd fully expect that to
David E. Wheeler da...@kineticode.com writes:
On May 18, 2011, at 10:30 AM, Dimitri Fontaine wrote:
The other problem is that the facility we need to provide the most is
binary distributions (think apt-get). Lots of site won't ever compile
stuff on their production servers. So while PGXN is
On May 18, 2011, at 1:23 PM, Tom Lane wrote:
I think building tools so that PGXN distributions are automatically
harvested and turned into StackBuilder/RPM/.deb binaries would be the place
to start on that.
Hmmm ... I think the real point of those policies about no source
builds is to
David E. Wheeler da...@kineticode.com writes:
I think building tools so that PGXN distributions are automatically
harvested and turned into StackBuilder/RPM/.deb binaries would be the place
to start on that.
Well, I'm not sure I buy into that idea, I need to think about it some
more. The
On May 18, 2011, at 1:47 PM, Dimitri Fontaine wrote:
Well, I'm not sure I buy into that idea, I need to think about it some
more. The thing with debian for example is that the package building
needs to be all automatic, and determistic — you're not granted to have
the next version build a
On Wed, May 18, 2011 at 13:47, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
David E. Wheeler da...@kineticode.com writes:
I think building tools so that PGXN distributions are automatically
harvested and turned into StackBuilder/RPM/.deb binaries would be the place
to start on that.
Well,
On May 18, 2011, at 2:47 PM, Magnus Hagander wrote:
I don't see why it couldn't, at least for a fair number of
extensions.. It does require the ability to differentiate between
patch releases and feature releases, though, which I believe is
currently missing in pgxn (correct me if i'm wrong),
On Wed, May 18, 2011 at 14:49, David E. Wheeler da...@kineticode.com wrote:
On May 18, 2011, at 2:47 PM, Magnus Hagander wrote:
I don't see why it couldn't, at least for a fair number of
extensions.. It does require the ability to differentiate between
patch releases and feature releases,
On May 18, 2011, at 2:58 PM, Magnus Hagander wrote:
Does it support having both v 1.3.1 and v1.4.0 and v2.0.2 at the same
time? I somehow got the idea that old versions were removed when I
uploaded a new one, but I happy to be wrong :-)
The distribution has only one version, of course, but
On Wed, May 18, 2011 at 15:05, David E. Wheeler da...@kineticode.com wrote:
On May 18, 2011, at 2:58 PM, Magnus Hagander wrote:
Does it support having both v 1.3.1 and v1.4.0 and v2.0.2 at the same
time? I somehow got the idea that old versions were removed when I
uploaded a new one, but I
On May 18, 2011, at 3:08 PM, Magnus Hagander wrote:
The distribution has only one version, of course, but perl extensions in
9.1, you can include multiple versions of an extension in one distribution.
Won't that break if different (major) versions have different dependencies?
I don't
On Wed, May 18, 2011 at 15:17, David E. Wheeler da...@kineticode.com wrote:
On May 18, 2011, at 3:08 PM, Magnus Hagander wrote:
The distribution has only one version, of course, but perl extensions in
9.1, you can include multiple versions of an extension in one distribution.
Won't that
On May 18, 2011, at 3:22 PM, Magnus Hagander wrote:
If I include both version 1 and version 2 of an extension in one. And
version 2 has more dependencies than version 1 (or the other way
around). Then those dependencies will be required for version 1 as
well...
Yes. But if they're that
David E. Wheeler da...@kineticode.com writes:
Yes. But if they're that decoupled, then they ought to be in separate
distributions.
I somehow fail to picture how you map distributions with debian
packages. The simple way is to have a distribution be a single source
package that will produce as
On May 18, 2011, at 3:27 PM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com writes:
Yes. But if they're that decoupled, then they ought to be in separate
distributions.
I somehow fail to picture how you map distributions with debian
packages. The simple way is to have a
I have missed it if this was discussed before but ...
Would now be a good time to start deprecating the contrib/ directory as a way to
distribute Pg add-ons, with favor given to PGXN and the like instead?
It would make sense to leave contrib/ alone for 9.1, but I believe that it
should start
On 05/17/2011 01:31 PM, Darren Duncan wrote:
I have missed it if this was discussed before but ...
Would now be a good time to start deprecating the contrib/ directory as
a way to distribute Pg add-ons, with favor given to PGXN and the like
instead?
If PGXN moves into .Org infrastructure
On Tue, May 17, 2011 at 9:45 PM, Joshua D. Drake j...@commandprompt.com wrote:
On 05/17/2011 01:31 PM, Darren Duncan wrote:
I have missed it if this was discussed before but ...
Would now be a good time to start deprecating the contrib/ directory as
a way to distribute Pg add-ons, with favor
On Tue, May 17, 2011 at 4:45 PM, Joshua D. Drake j...@commandprompt.com wrote:
On 05/17/2011 01:31 PM, Darren Duncan wrote:
I have missed it if this was discussed before but ...
Would now be a good time to start deprecating the contrib/ directory as
a way to distribute Pg add-ons, with favor
Robert Haas wrote:
On Tue, May 17, 2011 at 4:45 PM, Joshua D. Drake j...@commandprompt.com wrote:
On 05/17/2011 01:31 PM, Darren Duncan wrote:
I have missed it if this was discussed before but ...
Would now be a good time to start deprecating the contrib/ directory as
a way to distribute Pg
On Tue, 2011-05-17 at 13:45 -0700, Joshua D. Drake wrote:
If PGXN moves into .Org infrastructure (which I believe is currently
the plan) then yes, contrib should go away.
Well, it is not an enough reason to kick contrib off. I am not aware
that PGXN is a community driven project, and not
On Tue, 2011-05-17 at 20:37 -0700, Darren Duncan wrote:
Are the individual projects in contrib/ also distributed separately
from Pg, on their own release schedules,
No.
If the only way to get a contrib/ project is bundled with Pg, then the
project developers and users don't get the
26 matches
Mail list logo
