On Wed, May 18, 2011 at 13:47, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
> "David E. Wheeler" <david@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 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/
