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.