Re: deprecating contrib for PGXN

On Wed, May 18, 2011 at 13:47, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> "David E. Wheeler" <david(at)kineticode(dot)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 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 different set of binary packages.
>
> We're working about that very point with postgresql-X.Y-extension
> packages so that you can have a new binary package produced when you add
> support for a new major version, but we're not there yet.  Having the
> set of binary packages change manually is ok, but debian also have the
> concept of binNMU which is an infrastructure forced rebuild if you wish
> (picture libc upgrades).
>
> So, given how the debian packaging actually works, having something
> automated that works from “distributions” which in PGXN can contain
> several extensions — I'm not seeing it.  It looks a little like how
> things work in the Java world with jar and war packaging…

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), but that's a
solvable problem, no?

Also, if it has several extensions, it should generate several DEB's -
assuming they're independent extensions, right? If so, where's the
problem?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/