Re: Core Extensions relocation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Core Extensions relocation
Date
Msg-id 15270.1321626905@sss.pgh.pa.us
Whole thread Raw
In response to Re: Core Extensions relocation  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: Core Extensions relocation
Re: Core Extensions relocation
Re: Core Extensions relocation
List pgsql-hackers
Greg Smith <greg@2ndQuadrant.com> writes:
> On 11/17/2011 03:18 PM, Peter Eisentraut wrote:
>> Who's to say that after this, the core extensions won't end up in a new
>> separate package postgresql-extensions (or similar) or might even stay
>> in postgresql-contrib, for compatibility?

> I don't know why packagers would make an active decision that will make 
> their lives more difficult, with no benefit to them and a regression 
> against project recommendations for their users.

Why do you figure that, exactly?  The path of least resistance will
be precisely to leave everything packaged as it is, in a single
postgresql-contrib module.  I'm pretty likely to do that myself for
Fedora and RHEL.  Subdividing/rearranging contrib makes the packager's
life more complicated, *and* makes his users' lives more complicated,
if only because things aren't where they were before.  It seems unlikely
to happen, at least in the near term.

> And if some wanted to wander this way, they'll end up having to maintain 
> a doc patch to address the fact that they've broken with project 
> recommendations.  This text in what I submitted will no longer be true:

You're assuming anybody will notice or care about that text, if indeed
it gets committed/released with that wording at all.

The upstream project can't force these decisions on packagers, and it
doesn't help to go about under the illusion that we can.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: RangeVarGetRelid()
Next
From: Tom Lane
Date:
Subject: Re: vpath builds and verbose error messages