From owner-freebsd-ports@freebsd.org Tue Aug 4 09:11:34 2015 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C56C69B360C for ; Tue, 4 Aug 2015 09:11:34 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A016D9D4 for ; Tue, 4 Aug 2015 09:11:34 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9F24D9B360B; Tue, 4 Aug 2015 09:11:34 +0000 (UTC) Delivered-To: ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EB3E9B360A for ; Tue, 4 Aug 2015 09:11:34 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44DF59D1; Tue, 4 Aug 2015 09:11:34 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wibxm9 with SMTP id xm9so156731578wib.0; Tue, 04 Aug 2015 02:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=/wMHwUFV4FV24a8UWpUsKpNihI4OVH2leftNBCCU88w=; b=FnhRD/kzr9oHLcx4n2mYKtMbpdOFmF3P3Ju7I0lXqfxWvEZurA0jzAMWEsav+TmuyZ uTSAzBlER0/qU5PSw/fXLE5YxRQS/KvogLHcm9259Pyv7a4GzWtE4UWrYb8/rG/kGgSL XXtU+Ux6mdjMRYjowG5HOPeorrzx8xyyQEWa8Ur2HDR2uRPCzu5Fi3wuoy3j8wi2stoT YEMfv0FwIZ2xaXugu/VeqahAr0L9I2VzRnR2uaXK+BnqBVH2etYMrp3ISorMHp6K0yCr 0kPIbT2mAFx7cz33PjjRZCfeVyfh7mCw2MYF1ZHo0EoruToXKQzw2ncvuJpBvptJnfPm OyGg== X-Received: by 10.180.74.115 with SMTP id s19mr41384561wiv.18.1438679492632; Tue, 04 Aug 2015 02:11:32 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id s1sm1262568wix.13.2015.08.04.02.11.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2015 02:11:31 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 4 Aug 2015 11:11:29 +0200 From: Baptiste Daroussin To: Palle Girgensohn Cc: Shane Ambler , "pgsql@FreeBSD.org" , "ports@FreeBSD.org" Subject: Re: Proposal to fix postgresql package maintainance nightmare Message-ID: <20150804091128.GA31243@ivaldir.etoilebsd.net> References: <20150721094627.GD21594@ivaldir.etoilebsd.net> <55AE327F.8040300@ShaneWare.Biz> <20150721120342.GG21594@ivaldir.etoilebsd.net> <7239E352-D053-4EB5-8561-66924C031096@pingpong.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <7239E352-D053-4EB5-8561-66924C031096@pingpong.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 09:11:34 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 04, 2015 at 10:54:03AM +0300, Palle Girgensohn wrote: >=20 >=20 >=20 >=20 > > 21 jul 2015 kl. 15:03 skrev Baptiste Daroussin : > >=20 > >> On Tue, Jul 21, 2015 at 09:22:31PM +0930, Shane Ambler wrote: > >>> On 21/07/2015 19:16, Baptiste Daroussin wrote: > >>> Hi, > >>>=20 > >>> We do manage a bunch of postgresql servers on FreeBSD, and I really f= ind the > >>> current model of packages postgresql is a nightmare on FreeBSD. > >>>=20 > >>> Let's first start with the current issues. > >>> - Impossible to have tools from both old and new version at the same = time (which > >>> is necessary to upgrade db and prepare upgrades of db) > >>> - Impossible to chose the version we want to run in production withou= t having to > >>> rebuild the packages and the whole ports tree with a specific defau= lt. > >>> - Nightmare each time a new default version is set in the ports tree. > >>=20 > >> Sounds like a good plan, I am not a heavy postgresql user but I have > >> set the default pg version in make.conf to prevent unexpected new > >> versions going in during port updates when I didn't think of doing > >> upgrade steps. > >>=20 > >>> Here is my proposal to fix that. > >>>=20 > >>> Having one single postgresql-client package always on the latest stab= le version > >>> (backward compability being very good) providing the client cli tools= and the > >>> libraries (those libraries will be used for everything in the ports t= ree > >>> needing to talk to postgresql) > >>>=20 > >>> Have one full postgresql package per supported version upstream self = installing > >>> itself into let's say: /usr/local/postgresql94 and symlinks all the c= lient tools > >>> to /usr/local/bin suffixed by the version psql94 pg_bla94 etc. > >>=20 > >> Don't want to start a debate but thought I would mention as food for= =20 > >> thought -- > >>=20 > >> I'm not sure of any strong need to have more than one pg client version > >> available. The newer client can connect to any older server and I don't > >> know of any issues when an old client connects to a newer server. > >=20 > > That is why I propose only one client for regular users > >>=20 > >>> That way everything talk to pgsql will only depend on one postgresql-= client > >>> packages that will smoothly be upgraded to newer versions. > >>>=20 > >>> All database administrators will have the ability to chose the produc= tion > >>> version they do want without having to worry about a default version. > >>>=20 > >>> They can install multiple version in parallel and deal with upgrade t= he way they > >>> want having access to both versions of the tools of the same time. > >>>=20 > >>> Any opinion on that change? Any idea one how to make the upgrade path= as > >>> transparent as possible for current setup? (beside of course adding a= n UPDATING > >>> entry) > >>=20 > >> I think allowing multiple pg server versions is a good idea, this can > >> prevent old binary versions being removed before the data update proce= ss. > >>=20 > >> A new upgrade command could be added so we can do `service postgresql > >> upgrade` which tests for existing paths, defines old and new dirs and > >> runs pg_upgrade. > >>=20 > >> The rc script could either add a version postfix to the data dir path > >> or test PG_VERSION content to decide if data gets moved to data-old so > >> new versions being started won't see older version data. Lack of up to > >> date data dirs can lead to "You need to perform an upgrade first." > >> Different disk usage (filecount?) for old and new data dir can lead to > >> "Have you upgraded your old data?" > >>=20 > >> I don't think an upgrade step could be added during a port build, it > >> would have to be at server start in the rc script. I wouldn't add an > >> automatic upgrade step unless it was enabled by the user. > >=20 > > 100% agree, at first I would not even propose an automatic upgrade mech= anism I > > find it too dangerous by design I would expect admins to do upgrade the= mselves > > preparing it etc. > >=20 > > By upgrade patch I was more thinking when a user will make pkg upgrade = and get > > the new scheme I want everything to be safe and smooth (transparent) fr= om what I > > already tested this is the case now, but hey maybe someone has figured = out > > something that could be wrong. > >=20 > > Best regards, > > Bapt >=20 > Hi, >=20 > Sorry for not joining the conversation earlier. Did anything more happen = here? Don't worry I would not have pushed any big change like this without you reviewing and validating first :) >=20 > I did some test work a few years ago to make it possible to have multiple= versions installed in parallel. My approach then was that of lib/pgsqlNN a= nd symlinks for the default version, similar to how macports do it.=20 >=20 > Reading the discussion in this thread, one of the main goals would be to = ease dependency management for ports depending on PostgreSQL. My previous a= pproach would not really remedy that problem.=20 >=20 > Suggesting just one client install is not perfect either, since psql's in= ternal commands, \[a-zA-Z]+, are somewhat linked to the version on the serv= er. Though these commands rarely changes, it happens.=20 Yup that is what I figured out. >=20 > What is extremely stable, though, is libpq.so.5. And isn't that what most= ports depend upon? >=20 > So the best would perhaps be to separate postgresql-libpq that always use= s the latest version (?) and have postgresqlNN-(client|server|contrib) like= now, except that the client of course is stripped from libpq? Yes that would do the trick. I have been busy in other area, but that is still in my target. Fine with m= e if you want to take over that job, I'll be happy to review/test it. Otherwise = I may send you a patch when I have something working. Best regards, Bapt --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlXAgcAACgkQ8kTtMUmk6Ex3WwCdGgcuSNj/vDcKCI+/CCTw6lTd SBgAnjf9GnnClQ2rOdV1ONEb+BI4ph1M =u7k6 -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK--