Re: deprecating contrib for PGXN
От | David E. Wheeler |
---|---|
Тема | Re: deprecating contrib for PGXN |
Дата | |
Msg-id | 365F2DC9-F53D-4B68-9D4F-E858F06DEE14@kineticode.com обсуждение исходный текст |
Ответ на | Re: deprecating contrib for PGXN (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Список | pgsql-hackers |
On May 18, 2011, at 1:47 PM, Dimitri Fontaine wrote: > 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 think it must be my ignorance of Debian (and Java) packaging at work here, because I don't understand any of the above(except the par where you need to think about it some more, which is smart). > FYI, I'm still working on apt.postgresql.org so that we have debian > packaging for all major versions here, and all extensions for all those > major versions too. It's not the first item on my TODO list, but we > will get there eventually — this year I would figure, we even have a > team forming. That sounds awesome. Best, David
В списке pgsql-hackers по дате отправления: