On Wed, May 18, 2011 at 13:47, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > "David E. Wheeler" <da...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
