21 Articles tagged “Debian”
Some skytools related new today, it’s been a while. For those who where at my FOSDEM’s talk about Implementing High Availability you might have heard that I really like working with PGQ. A new version has been released a while ago, and the most recent verion is now 3.1.3, as announced in the Skytools 3.1.3 email.
Skytools 3.1.3 enters debian First news is that Skytools 3.1.3 has been entering debian today (I hope that by the time you reach that URL, it’s been updated to show information according to the news here, but I might be early).
After talking about it for a very long time, work finally did begin! I’m talking about the apt.postgresql.org build system that will allow us, in the long run, to propose debian versions of binary packages for PostgreSQL and its extensions, compiled for a bunch of debian and ubuntu versions.
We’re now thinking to support the i386 and amd64 architectures for lenny, squeeze, wheezy and sid, and also for maverick and natty, maybe oneiric too while at it.
As of pretty recently, pgfincore is now in debian, as you can see on its postgresql-9.0-pgfincore page. The reason why it entered the debian archives is that it reached the 1.0 release!
Rather than talking about what pgfincore is all about ( A set of functions to manage pages in memory from PostgreSQL), I will talk about its packaging and support as a debian package. Here’s the first example of a modern multi-version packaging I have to offer.
We still have this problem to solve with extensions and their packaging. How to best organize things so that your extension is compatible with before 9.1 and 9.1 and following releases of PostgreSQL?
Well, I had to do it for the ip4r contribution, and I wanted the following to happen:
dpkg-deb: building package
postgresql-8.3-ip4r' ... dpkg-deb: building packagepostgresql-8.4-ip4r’ … dpkg-deb: building package
postgresql-9.0-ip4r' ... dpkg-deb: building packagepostgresql-9.1-ip4r’ … And here’s a simple enough way to achieve that.
While Magnus is all about PG Conf EU already, you have to realize we’re just landed back from PG Con in Ottawa. My next stop in the annual conferences is CHAR 11, the Clustering, High Availability and Replication conference in Cambridge, 11-12 July. Yes, on the old continent this time.
This year’s pgcon hot topics, for me, have been centered around a better grasp at SSI and DDL Triggers. Having those beasts in PostgreSQL would allow for auditing, finer privileges management and some more automated replication facilities.
While currently too busy at work to deliver much Open Source contributions, let’s debunk an old habit of PostgreSQL extension authors. It’s all down to copy pasting from contrib, and there’s no reason to continue doing $libdir this way ever since 7.4 days.
Let’s take an example here, with the prefix extension. This one too will need some love, but is still behind on my spare time todo list, sorry about that.
Following up on the very popular emacs-starter-kit, I’m now proposing the emacs-kicker. It’s about the .emacs file you’ve seen in older posts here, which I maintain for some colleagues. After all, if they find it useful, some more people might to, so I’ve decided to publish it.
What you’ll find is a very simple 128 lines Emacs user init file, based on el-get for external packages. A not so random selection of those is used, here’s the list when you hide some details:
I’ve been working on skytools3 packaging lately. I’ve been pushing quite a lot of work into it, in order to have exactly what I needed out of the box, after some 3 years of production and experiences with the products. Plural, yes, because even if pgbouncer and plproxy are siblings to the projets (same developers team, separate life cycle and releases), then skytools still includes several sub-projects.
Here’s what the skytools3 packaging is going to look like:
If you’ve not been following closely you might have missed out on extensions integration. Well, Tom spent some time on the patches I’ve been preparing for the last 4 months. And not only did he commit most of the work but he also enhanced some parts of the code (better factoring) and basically finished it.
At the previous developer meeting his advice was to avoid putting too much into the very first version of the patch for it to stand its chances of being integrated, and while in the review process more than one major PostgreSQL contributor expressed worries about the size of the patch and the number of features proposed.