The current ebuild installs slony1 for the currently-eselected version of postgres only. This makes it impossible to use slony with multiple slots of postgres on the same machine (typically to do a downtime-less upgrade). I'm attaching an updated ebuild which uses SLOTs for slony1 itself, trying to be as consistent as possible with the postgresql ebuild's SLOTs. I initially tried to install slony for all postgresql slots using a single slony1 slot and some use-flags, but this approach seemed cleaner (and easyer considering slony's build system). Since we want multiple slots for the same version of slony, I'm using the ebuild version (-rxxx) to distinguish the files. Not best-practice, but I'm open to suggestions. As part of fixing file colisions between slots, this ebuild fixes bug #395689. Reproducible: Always
Created attachment 299073 [details] SLOTed slony1 ebuild --- /usr/portage/dev-db/slony1/slony1-2.0.7-r1.ebuild 2011-08-11 00:47:31.000000000 +0200 +++ publish/slony1-2.0.7-r832.ebuild 2012-01-16 17:50:02.084170524 +0100 @@ -16,33 +16,17 @@ http://main.slony.info/downloads/2.0/source/${P}-docs.tar.bz2" LICENSE="BSD" -SLOT="0" +#SLOT="$(sed -r 's/r(.)(.).*/\1.\2/' <<< ${PR})" +SLOT="8.3" KEYWORDS="~amd64 ~ppc ~x86" -DEPEND="|| ( - dev-db/postgresql-base:9.0[threads] - dev-db/postgresql-base:8.4[threads] - dev-db/postgresql-base:8.3[threads] - dev-db/postgresql-base:9.1[threads] - ) - || ( - dev-db/postgresql-server:9.0 - dev-db/postgresql-server:8.4 - dev-db/postgresql-server:8.3 - dev-db/postgresql-server:9.1 - ) - perl? ( dev-perl/DBD-Pg ) -" +DEPEND="!dev-db/slony1:0 + dev-db/postgresql-base:${SLOT}[threads] + dev-db/postgresql-server:${SLOT} + perl? ( dev-perl/DBD-Pg )" pkg_setup() { - local PGSLOT="$(postgresql-config show)" - if [[ ${PGSLOT//.} < 83 ]] ; then - eerror "You must build ${CATEGORY}/${PN} against PostgreSQL 8.3 or higher." - eerror "Set an appropriate slot with postgresql-config." - die "postgresql-config not set to 8.3 or higher." - fi - - if [[ ${PGSLOT//.} > 90 ]] ; then + if [[ ${SLOT//.} > 90 ]] ; then ewarn "You are building ${CATEGORY}/${PN} against a version of PostgreSQL greater than 9.0." ewarn "This is neither supported here nor upstream." ewarn "Any bugs you encounter should be reported upstream." @@ -54,21 +38,27 @@ } src_configure() { - econf $(use_with perl perltools) + econf $(use_with perl perltools) --with-pgconfigdir=/usr/lib/postgresql-${SLOT}/bin/ } src_install() { + sed -i "s@toolsbin=.*@toolsbin=/usr/lib/slony1-${SLOT}/bin/@" Makefile.global + sed -i "s@slonbindir=.*@slonbindir=/usr/lib/slony1-${SLOT}/bin/@" Makefile.global emake DESTDIR="${D}" install dodoc HISTORY-1.1 INSTALL README SAMPLE TODO UPGRADING doc/howto/*.txt - doman "${S}"/doc/adminguide/man{1,7}/* + for i in "${S}"/doc/adminguide/man{1,7}/; do + insinto /usr/share/slony1-${SLOT}/man/$(basename $i) + doins ${i}/* + done + docompress /usr/share/slony1-${SLOT}/man if use doc ; then cd "${S}"/doc dohtml -r * fi - newinitd "${FILESDIR}"/slony1.init slony1 - newconfd "${FILESDIR}"/slony1.conf slony1 + newinitd <(sed "s/{SLOT}/${SLOT}/g" < "${FILESDIR}"/slony1.init) slony1-${SLOT} + newconfd <(sed "s@LOGFILE=.*@LOGFILE=/var/log/slony1-${SLOT}.log@" "${FILESDIR}"/slony1.conf) slony1-${SLOT} }
Created attachment 299075 [details] SLOTed slony1 init file --- /usr/portage/dev-db/slony1/files/slony1.init 2007-03-08 00:18:21.000000000 +0100 +++ /usr/local/portage/dev-db/slony1/files/slony1.init 2012-01-16 17:24:12.115547798 +0100 @@ -3,18 +3,20 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/dev-db/slony1/files/slony1.init,v 1.2 2007/03/07 23:18:21 nakano Exp $ +pidfile=/var/run/slony1-{SLOT}.pid + depend() { - need postgresql + need postgresql-{SLOT} } start() { - ebegin "Starting slony1" - /usr/bin/slon -p /var/run/slony1.pid -d $LOGLEVEL $CLUSTER "dbname=$DBNAME user=$DBUSER host=$DBHOST" >> $LOGFILE 2>&1 & + ebegin "Starting slony1-{SLOT}" + /usr/lib/slony1-{SLOT}/bin/slon -p $pidfile -d $LOGLEVEL $CLUSTER "dbname=$DBNAME user=$DBUSER host=$DBHOST" >> $LOGFILE 2>&1 & while : do cnt=$(($cnt + 1)) - if [ -f "/var/run/slony1.pid" ]; then + if [ -f $pidfile ]; then ret=0 break fi @@ -30,8 +32,8 @@ } stop() { - ebegin "Stopping slony1" - kill `cat /var/run/slony1.pid` + ebegin "Stopping slony1-{SLOT}" + kill `cat $pidfile` eend $? }
Created attachment 299077 [details] SLOTed slony1 conf file --- /usr/portage/dev-db/slony1/files/slony1.conf 2007-03-08 00:18:21.000000000 +0100 +++ /usr/local/portage/dev-db/slony1/files/slony1.conf 2012-01-16 17:23:44.786889453 +0100 @@ -8,5 +8,5 @@ DBUSER=postgres DBNAME=your_database_name DBHOST=localhost -LOGFILE=/var/lib/postgresql/data/slony1.log +LOGFILE= LOGLEVEL=1 # 1(minimum)..4(maximum)
It would probably be interesting to make the postgresql eselect module handle the slony slots as well.
(In reply to comment #0) > The current ebuild installs slony1 for the currently-eselected version of > postgres only. This makes it impossible to use slony with multiple slots of > postgres on the same machine (typically to do a downtime-less upgrade). > > I'm attaching an updated ebuild which uses SLOTs for slony1 itself, trying to > be as consistent as possible with the postgresql ebuild's SLOTs. > > I initially tried to install slony for all postgresql slots using a single > slony1 slot and some use-flags, but this approach seemed cleaner (and easyer > considering slony's build system). > > Since we want multiple slots for the same version of slony, I'm using the > ebuild version (-rxxx) to distinguish the files. Not best-practice, but I'm > open to suggestions. One of the features of Slony-I is that it can replicate between different major versions of PostgreSQL. What's preventing the zero-downtime upgrade?
(In reply to comment #5) > One of the features of Slony-I is that it can replicate between different major > versions of PostgreSQL. What's preventing the zero-downtime upgrade? Wether slony is used for replication, upgrade, or anything else, it needs to be installed on both the slave(s) and the master database. That installation consists of 1) in-db data, 2) system executables, and 3) postgres libraries. My ebuild attempts to fix item 3) : the libraries are only installed for the currently-eselected version of postgres. This makes is impossible to use the slony ebuild between two different postgres versions on the same host (I know ideally two different hosts should be used, but that's often not practical). It also ties the slony install to a specific postgres version at installation time, which is a good recipe for surprises.
That said, I am not sure whether using slots is the best approach, and the use of the "-rxxx" version suffix to differentiate sloted ebuilds seems ugly. Maybe having an ebuild that installs to all postgres versions in one go would be better, but I couldn't figure out how to do the configure/make/install steps multiple times (my ebuild-fu isn't great). It might also be wise to merge this ebuild development with bug #217868 (multi-cluster support) in case one fix influences the other. So... This ebuild fixes a real problem, but I'm open to suggestion about the implementation of the fix.
I agree, there is a problem to be fixed here. Slotting is not the way to go, though. We can modify the ebuild to build and install against each PostgreSQL slot using a for loop for each step. There is an eclass floating around that is intended to implement this very feature so we wouldn't have to rewrite every ebuild entirely. I'm working on migrating it to the pgsql-patches git repo so that I can get it working soon as this isn't the only ebuild that needs this solution.
So, I've finally gotten around to getting going on this, kind of, in the form of 2 new eclasses. https://github.com/titanofold/titanofold-gentoo-x86/tree/pgsql-eclass/eclass
commit 5e6704a19a5161f30ec02498b62a0af91de62c67 Author: Aaron W. Swenson <titanofold@gentoo.org> Date: Sun Jul 9 22:17:12 2017 -0400 dev-db/slony1: Use postgres-multi Now build and install against multiple versions. Use flag controlled dependency on the PostgreSQL slots eliminates too many slots being emerged. Bug: 399097, 623230 Package-Manager: Portage-2.3.6, Repoman-2.3.1
