On 05/09/2011 02:31 PM, Robert Haas wrote:
> I don't think we should be too obstinate about trying to twist the arm
> of packagers who (as Tom points out) will do whatever they want in
> spite of us, but the current state of contrib, with all sorts of
> things of varying type, complexity, and value mixed together cannot
> possibly be a good thing.
I think the idea I'm running with for now means that packagers won't
actually have to do anything. I'd expect typical packaging for 9.1 to
include share/postgresql/extension from the build results without being
more specific. You need to grab 3 files from there to get the plpgsql
extension, and I can't imagine any packager listing them all by name.
So if I dump the converted contrib extensions to put files under there,
and remove them from the contrib build area destination, I suspect they
will magically jump from the contrib to the extensions area of the
server package at next package build; no packager level changes
required. The more I look at this, the less obtrusive of a change it
seems to be. Only people who will really notice are users who discover
more in the basic server package, and of course committers with
backporting to do.
Since packaged builds of 9.1 current with beta1 seem to be in short
supply still, this theory looks hard to prove just yet. I'm very
excited that it's packaging week here however (rolls eyes), so I'll
check it myself. I'll incorporate the suggestions made since I posted
that test patch and do a bigger round of this next, end to end with an
RPM set as the output. It sounds like everyone who has a strong opinion
on what this change might look like has sketched a similar looking
bikeshed. Once a reasonable implementation is hammered out, I'd rather
jump to the big argument between not liking change vs. the advocacy
benefits to PostgreSQL of doing this; they are considerable in my mind.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
