Red Hat Bugzilla – Bug 127707
rfe: patch: slony replication engine
Last modified: 2013-07-02 23:01:47 EDT
Description of problem: It would be nice if the slony-1 replication engine was available from the distribution. As currently it can't be built without a compiled postgresql source tree it only makes sense to include it. The attached patch against postgresql 7.4.3-2 does so. Version-Release number of selected component (if applicable): 7.4.3-2 Additional info: Thanks.
Created attachment 101823 [details] patch against postgresql.spec (7.4.3-2)
Slony isn't even out of beta yet. When it gets past the "version 1.0" stage, we'll consider including it in Fedora. It won't be part of the core postgresql package though --- that would create severe release-management headaches, since slony is not on the same release schedule as core Postgres.
However, Tom, Slony requires a source tree on which to compile, so while separate packaging would be the nicest, is it even possible without a slony source RPM duplicating the postgresql source tree? Slony 1.0 non-beta has been released, incidentally. As it is a goal of mine to have the slony engine be the mechanism for upgrades, I personally want to include it, even though it will be a release headache. The nice part is that it can be compiled against any source tree, not just the latest version (although there is a sunrise version for it, I think 7.3 is the earliest tree it will compile against).
If Slony needs a source tree, then that's a Slony bug we'll have to fix ;-). I can't see a reason why it shouldn't be able to get by with the headers provided by the postgresql- devel RPM. Considering that it's supposed to be backend-version-independent, it can't really be touching any deep dark source code. I think it would be an absolutely fatal packaging error to put Slony into the same specfile as Postgres. We would very soon find ourselves in binds like having an older version of Slony in RPMs that are newer according to the RPM version number (because it's a newer PG release). That would mean that an "upgrade" could cause a user's system to go backwards. BTW, we need to break JDBC and pygresql out too, for the same reason. If you want to use Slony to support upgrades, we could conceivably make the postgresql- server package depend on the slony package. (I do not think this would create any circularity, because the slony-to-postgresql-devel dependency would be at build time not install time.) However, you have previously given lots of cogent reasons why trying to upgrade during RPM install is a bad idea, and I don't see that Slony eliminates any of those reasons. So I think we're still going to have to do the thing with concurrent installations of two Postgres versions.
Just having the header files around isn't enough. :( The postgresql sources needed to be compiled successfully with some sane options before attempting to compile slony-1. A completely separate package is okay with me. I seem to need slony-1 for a replication project and would like not to do OSS work that goes away from the upstream since it gets to be a maintenance issue after 1-2 years.