On May 18, 2011, at 3:27 PM, Dimitri Fontaine wrote:
> "David E. Wheeler" 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 b
"David E. Wheeler" 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 many binary packa
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 de
On Wed, May 18, 2011 at 15:17, David E. Wheeler 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 break if dif
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:05, David E. Wheeler 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 happy to be wro
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 14:49, David E. Wheeler 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, though, which I
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 wron
On Wed, May 18, 2011 at 13:47, Dimitri Fontaine wrote:
> "David E. Wheeler" 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 ide
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
"David E. Wheeler" 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 thing with debian fo
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
"David E. Wheeler" 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 a good tool,
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
On Wed, May 18, 2011 at 12:15 PM, David E. Wheeler 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 production server
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 05/18/2011 10:30 AM, Dimitri Fontaine wrote:
> Darren Duncan 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
Darren Duncan 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, and I guess they prefe
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
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 awa
Robert Haas wrote:
On Tue, May 17, 2011 at 4:45 PM, Joshua D. Drake 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 give
On Tue, May 17, 2011 at 4:45 PM, Joshua D. Drake 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 given to PG
On Tue, May 17, 2011 at 9:45 PM, Joshua D. Drake 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 given to PG
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 (whic
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
26 matches
Mail list logo
